| (non) modifiable attributes... [message #1128768] |
Mon, 07 October 2013 21:41  |
Eclipse User |
|
|
|
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?
(Maybe I've missed something embarrassingly obvious..)
cheers,
Miles
|
|
|
| Re: (non) modifiable attributes... [message #1129101 is a reply to message #1128768] |
Tue, 08 October 2013 05:30  |
| Eclipse User |
|
|
|
Miles,
Comments below.
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
|
|
|
| Re: (non) modifiable attributes... [message #1129438 is a reply to message #1129101] |
Tue, 08 October 2013 12:22 |
| Eclipse User |
|
|
|
Hi Ed...
Ed Merks wrote on Tue, 08 October 2013 05:30Miles,
> 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.
|
|
|
Powered by
FUDForum. Page generated in 0.08280 seconds
Home