It's not like we don't have enough meta-data to describe editability of features. There is volatile, transient, derived, changeable, unsettable. But none of them cover a case that comes up fairly frequently for me... allowing a value to be set once and only once. (It seems like changeable should cover this case, but instead it's for preventing setters altogether.) Maybe immutable would be a better name then (non) modifiable, but I'm wondering if any consideration was ever given to supporting something like this at the model level?

On 08/10/2013 3:42 AM, Miles Parker wrote:
> It's not like we don't have enough meta-data to describe editability
> of features. There is volatile, transient, derived, changeable,
> unsettable. But none of them cover a case that comes up fairly
> frequently for me... allowing a value to be set once and only once.
So you need to prevent it being set a second time? Is there are
security issues involved?
> (It seems like changeable should cover this case, but instead it's for
> preventing setters altogether.)
Of course.
> Maybe immutable would be a better name then (non) modifiable, but I'm
> wondering if any consideration was ever given to supporting something
> like this at the model level?
No. One question is whether something like this is for security reasons
or for bug detection because of course you can always only set it once
by convention...
>
> (Maybe I've missed something embarrassingly obvious..)
>
> cheers,
>
> Miles

Miles,
> unsettable. But none of them cover a case that comes up fairly
> frequently for me... allowing a value to be set once and only once.
So you need to prevent it being set a second time? Is there are
security issues involved?
...
No. One question is whether something like this is for security reasons
or for bug detection because of course you can always only set it once
by convention...

It's more of a data integrity thing. It often doesn't make sense to change the name or other basic attributes of something after it has been initially created. For example, a Library patron's name may change, but the title of a book shouldn't be changing after it has been acquired. (Of course this assumes that corrections can never be made either.) So note that there is an implication of a change commit that freezes the value.

Also, think about any scenario in which some value is imported/synchronized from an external system but should then be treated as immutable. Essentially there you want to be able to assign the state but ensure that it cannot be reassigned from the API.