[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Default Value of an inherited EAttribute or EReference

Hello John,

you wrote that you want to overwrite a default, now you write that you want 
to have another initializer. In my opinion these requirements are slightly 
different!

The difference, as far as I would interpret it, is, that an initial value is 
only taken if and only if the owning class is created where the default is 
also taken when the attribute or reference is unset. This can be the case 
when it was explicitely unset (eUnset) or if it doens't even exist in an old 
persisted model (the attribute was newly introduced from one metamodel 
release to another).

Depending on what you really want, you have to do your implementations. 
Sometimes people just want to have a constant in the sub class, for example. 
In this case it would be ok to simpy overwrite the attribute getter (ugly, 
but... it helps :), which is by the way possible without touching the 
generated class.

Ciao, Michael



"John T.E. Timm" <johntimm@xxxxxxxxxx> wrote in message 
news:f5173b4323085cc23fc6c39ad64c0df7$1@xxxxxxxxxxxxxxxxxx
> So let's say that I define an EOperation "getFoo" in superclass A. And 
> then I define an EAttribute "foo" in subclass B. Are you suggesting that I 
> use the "Default Literal" option in conjunction with 
> OPTION_KEEP_DEFAULT_CONTENT on EAttribute foo in subclass B so that the 
> default gets serialized?
>
> In my particular application, I actually always want attr to be 
> serialized. So I guess what I am looking for is a way to "initialize" the 
> value of certain EAttributes and EReferences immediately after 
> instantiation without forcing the client code to do it explicitly... In my 
> particular model, I would have a superclass A with subclasses B, C, and D 
> where the only difference with B, C, and D is that there are some 
> constraints added and I want to "initialize" the value of certain 
> EAttributes and EReferences differently.
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> John,
>
>> Comments below.
>
>> John T.E. Timm wrote:
>>> Ed:
>>>
>>> Ed Merks wrote:
>>>
>>> "Or have just an operation on A with a name that is overloaded by the 
>>> attribute in B..."
>>>
>>> Could you please expain how this would work?
>> On A you define an operation getFoo and in B you define a feature "foo" 
>> which will implement getFoo.
>>>
>>> What about attaching annotations to the class with all of the default or 
>>> fixed values and then customizing the generated EFactory to do something 
>>> like this:
>>>
>>> public ClassB createClassB() {
>>>    ClassB instance = new ClassBImpl();
>>>    // look at annotations to determine what needs to be initialized here
>>>    instance.setAttr("someValue");
>>>    // ...
>>> }
>> You'll find that eIsSet returns true for "attr", so this value will be 
>> serialized, unlike what a true default would do.   If you unset "attr" 
>> and made a copy of ClassB, you'd find "attr" would be set in the copy but 
>> not in the original.
>>>
>>> Thanks,
>>>
>>> JT
>>>
>>>
>
>