Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » (non) modifiable attributes...
(non) modifiable attributes... [message #1128768] Mon, 07 October 2013 21:41 Go to next message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
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 Go to previous message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
Hi Ed...

Ed Merks wrote on Tue, 08 October 2013 05:30
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.
Previous Topic:Save disabled
Next Topic:Could not initialize class org.eclipse.emf.cdo.security.SecurityPackage
Goto Forum:
  


Current Time: Thu Jul 31 21:42:49 EDT 2014

Powered by FUDForum. Page generated in 0.02195 seconds