Home » Modeling » EMF » inherit two properties with the same name
|
Re: inherit two properties with the same name [message #415710 is a reply to message #415708] |
Wed, 02 January 2008 12:10 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Jörg,
Note that when you open a GenModel with errors, it displays an error
page, but if you look closely at the editor, you'll see it's a tabbed
editor with tabs at the bottom so you can actually still turn to the
main page. Ecore has never supported multiple features with the same
name. I would expect this to generate an XyzPackage with errors that
A_X are duplicate fields. If you make B an C both inherit from an X
class that introduces feature x you'll be fine. Or if you make at least
B or C define operations like getX and setX instead of a feature x
that's fine too. In general, you should think of the feature x more
like a Java field than like a Java method, i.e., if you have a base
class with field x and introduce another field x in the derived class,
you'll have two different fields both named x; if you had an accessor
method to return x you could only return one of the two x's.
Jörg Kiegeland wrote:
> In my metamodel, a class A inherits from classes B and C. Both classes
> B and class C define a property "x" of the same type. Now calling
> "Validate" on the model complains about this fact. For the same
> reason, I cannot open the generated .genmodel for this metamodel.
> However I want that both super-attributes are merged in one attribute
> of my sub class. I think this is possible by MOF but not by EMF, but I
> am not sure. However I think this was still possible with Eclipse <3.3
> since for this metamodel once (a long time ago..) working model code
> was generated.
>
> Any idea?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: inherit two properties with the same name [message #415738 is a reply to message #415710] |
Fri, 04 January 2008 16:20 |
Philipp Kutter Messages: 306 Registered: July 2009 |
Senior Member |
|
|
Hi, Ed.
You know, my favorite topic.
I do not want to propose anything concrete now, but I think,
that this is another area, where EMF can go beyond Java
Does the MOF-standard tell what they think about
class A and class B -> A, both having the same feature?
In our daily work, we need to specialize the behavior of features
a lot, and since EMF does not allow us to repeat the feature in the
model we created OVERRIDE_OCL annotations, which are attached to the
class, rather the feature. This works fine for us.
By the way, what is the behavior of an Interface? I assume there you
allow multiple features, aren't you? I mean an interface with
feature X of type Y just means that the class must have feature X of
type Y. If I let a class implement an EMF generated interface, it would
be cool, if I do not have to remove the feature from the EMF Class.
Especially, since two classes may want to implement the same interface
with different options on the feature.
Botomline, I think Interfaces could be the place that allows duplicate
features, and in classes the standard behavior could be kept.
Sorry for insisting,
Best, Philipp
Ed Merks wrote:
> Jörg,
>
> Note that when you open a GenModel with errors, it displays an error
> page, but if you look closely at the editor, you'll see it's a tabbed
> editor with tabs at the bottom so you can actually still turn to the
> main page. Ecore has never supported multiple features with the same
> name. I would expect this to generate an XyzPackage with errors that
> A_X are duplicate fields. If you make B an C both inherit from an X
> class that introduces feature x you'll be fine. Or if you make at least
> B or C define operations like getX and setX instead of a feature x
> that's fine too. In general, you should think of the feature x more
> like a Java field than like a Java method, i.e., if you have a base
> class with field x and introduce another field x in the derived class,
> you'll have two different fields both named x; if you had an accessor
> method to return x you could only return one of the two x's.
>
>
> Jörg Kiegeland wrote:
>> In my metamodel, a class A inherits from classes B and C. Both classes
>> B and class C define a property "x" of the same type. Now calling
>> "Validate" on the model complains about this fact. For the same
>> reason, I cannot open the generated .genmodel for this metamodel.
>> However I want that both super-attributes are merged in one attribute
>> of my sub class. I think this is possible by MOF but not by EMF, but I
>> am not sure. However I think this was still possible with Eclipse <3.3
>> since for this metamodel once (a long time ago..) working model code
>> was generated.
>>
>> Any idea?
|
|
|
Re: inherit two properties with the same name [message #415746 is a reply to message #415738] |
Fri, 04 January 2008 19:12 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Philipp,
Comments below.
Philipp W. Kutter wrote:
> Hi, Ed.
> You know, my favorite topic.
And one of my least favorite. I didn't have the heart to point out
that without to the two constants, the eGet for the feature whose
constant was removed won't work.
>
> I do not want to propose anything concrete now, but I think,
> that this is another area, where EMF can go beyond Java
Oh dear!
>
> Does the MOF-standard tell what they think about
> class A and class B -> A, both having the same feature?
I'm not sure actually. They've not defined the EMOF mapping onto Java
and it's at this level you start to get into problems you might be able
to ignore. If the features had different types, the couldn't be merged
so that's certainly more likely to be considered wrong.
>
>
> In our daily work, we need to specialize the behavior of features
> a lot, and since EMF does not allow us to repeat the feature in the
> model we created OVERRIDE_OCL annotations, which are attached to the
> class, rather the feature. This works fine for us.
Good. I like that better. :-P
>
> By the way, what is the behavior of an Interface? I assume there you
> allow multiple features, aren't you? I mean an interface with
> feature X of type Y just means that the class must have feature X of
> type Y.
An interface is just an EClass for which there is so generated Impl and
hence which must be abstract.
> If I let a class implement an EMF generated interface, it would
> be cool, if I do not have to remove the feature from the EMF Class.
The problem is you will still have two different feature objects in the
list of eAllStructuralFeatures and when you get notifications, you only
get notifications for one feature, so having two synonymous features
results in an endless (in my opinion) stream of special cases that start
to permeate the system.
> Especially, since two classes may want to implement the same interface
> with different options on the feature.
It's more flexible to define an interface with operations. Then one
class can specialize it by implementing it as a feature and another
could specialize it by deriving it from something...
>
> Botomline, I think Interfaces could be the place that allows duplicate
> features, and in classes the standard behavior could be kept.
>
> Sorry for insisting,
I'm still refusing. There are too many complications that will arise
that must be taken into account everywhere. It's too much complexity
that's not easily justified by the benefits.
> Best, Philipp
>
> Ed Merks wrote:
>> Jörg,
>>
>> Note that when you open a GenModel with errors, it displays an error
>> page, but if you look closely at the editor, you'll see it's a tabbed
>> editor with tabs at the bottom so you can actually still turn to the
>> main page. Ecore has never supported multiple features with the
>> same name. I would expect this to generate an XyzPackage with errors
>> that A_X are duplicate fields. If you make B an C both inherit from
>> an X class that introduces feature x you'll be fine. Or if you make
>> at least B or C define operations like getX and setX instead of a
>> feature x that's fine too. In general, you should think of the
>> feature x more like a Java field than like a Java method, i.e., if
>> you have a base class with field x and introduce another field x in
>> the derived class, you'll have two different fields both named x; if
>> you had an accessor method to return x you could only return one of
>> the two x's.
>>
>>
>> Jörg Kiegeland wrote:
>>> In my metamodel, a class A inherits from classes B and C. Both
>>> classes B and class C define a property "x" of the same type. Now
>>> calling "Validate" on the model complains about this fact. For the
>>> same reason, I cannot open the generated .genmodel for this
>>> metamodel. However I want that both super-attributes are merged in
>>> one attribute of my sub class. I think this is possible by MOF but
>>> not by EMF, but I am not sure. However I think this was still
>>> possible with Eclipse <3.3 since for this metamodel once (a long
>>> time ago..) working model code was generated.
>>>
>>> Any idea?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: inherit two properties with the same name [message #415759 is a reply to message #415746] |
Fri, 04 January 2008 21:10 |
Philipp Kutter Messages: 306 Registered: July 2009 |
Senior Member |
|
|
Hi, Ed.
I think I agree with what you say.
Using operations in the interfaces will do the job.
Best Regards, Philipp
Ed Merks wrote:
> Philipp,
>
> Comments below.
>
> Philipp W. Kutter wrote:
>> Hi, Ed.
>> You know, my favorite topic.
> And one of my least favorite. I didn't have the heart to point out
> that without to the two constants, the eGet for the feature whose
> constant was removed won't work.
>>
>> I do not want to propose anything concrete now, but I think,
>> that this is another area, where EMF can go beyond Java
> Oh dear!
>>
>> Does the MOF-standard tell what they think about
>> class A and class B -> A, both having the same feature?
> I'm not sure actually. They've not defined the EMOF mapping onto Java
> and it's at this level you start to get into problems you might be able
> to ignore. If the features had different types, the couldn't be merged
> so that's certainly more likely to be considered wrong.
>>
>>
>> In our daily work, we need to specialize the behavior of features
>> a lot, and since EMF does not allow us to repeat the feature in the
>> model we created OVERRIDE_OCL annotations, which are attached to the
>> class, rather the feature. This works fine for us.
> Good. I like that better. :-P
>>
>> By the way, what is the behavior of an Interface? I assume there you
>> allow multiple features, aren't you? I mean an interface with
>> feature X of type Y just means that the class must have feature X of
>> type Y.
> An interface is just an EClass for which there is so generated Impl and
> hence which must be abstract.
>> If I let a class implement an EMF generated interface, it would
>> be cool, if I do not have to remove the feature from the EMF Class.
> The problem is you will still have two different feature objects in the
> list of eAllStructuralFeatures and when you get notifications, you only
> get notifications for one feature, so having two synonymous features
> results in an endless (in my opinion) stream of special cases that start
> to permeate the system.
>> Especially, since two classes may want to implement the same interface
>> with different options on the feature.
> It's more flexible to define an interface with operations. Then one
> class can specialize it by implementing it as a feature and another
> could specialize it by deriving it from something...
>>
>> Botomline, I think Interfaces could be the place that allows duplicate
>> features, and in classes the standard behavior could be kept.
>>
>> Sorry for insisting,
> I'm still refusing. There are too many complications that will arise
> that must be taken into account everywhere. It's too much complexity
> that's not easily justified by the benefits.
>> Best, Philipp
>>
>> Ed Merks wrote:
>>> Jörg,
>>>
>>> Note that when you open a GenModel with errors, it displays an error
>>> page, but if you look closely at the editor, you'll see it's a tabbed
>>> editor with tabs at the bottom so you can actually still turn to the
>>> main page. Ecore has never supported multiple features with the
>>> same name. I would expect this to generate an XyzPackage with errors
>>> that A_X are duplicate fields. If you make B an C both inherit from
>>> an X class that introduces feature x you'll be fine. Or if you make
>>> at least B or C define operations like getX and setX instead of a
>>> feature x that's fine too. In general, you should think of the
>>> feature x more like a Java field than like a Java method, i.e., if
>>> you have a base class with field x and introduce another field x in
>>> the derived class, you'll have two different fields both named x; if
>>> you had an accessor method to return x you could only return one of
>>> the two x's.
>>>
>>>
>>> Jörg Kiegeland wrote:
>>>> In my metamodel, a class A inherits from classes B and C. Both
>>>> classes B and class C define a property "x" of the same type. Now
>>>> calling "Validate" on the model complains about this fact. For the
>>>> same reason, I cannot open the generated .genmodel for this
>>>> metamodel. However I want that both super-attributes are merged in
>>>> one attribute of my sub class. I think this is possible by MOF but
>>>> not by EMF, but I am not sure. However I think this was still
>>>> possible with Eclipse <3.3 since for this metamodel once (a long
>>>> time ago..) working model code was generated.
>>>>
>>>> Any idea?
|
|
|
Goto Forum:
Current Time: Sun Apr 28 02:51:55 GMT 2024
Powered by FUDForum. Page generated in 0.03133 seconds
|