Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » inherit two properties with the same name
inherit two properties with the same name [message #415708] Wed, 02 January 2008 10:15 Go to next message
Jörg Kiegeland is currently offline Jörg KiegelandFriend
Messages: 32
Registered: July 2009
Member
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 #415710 is a reply to message #415708] Wed, 02 January 2008 12:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 #415726 is a reply to message #415710] Thu, 03 January 2008 17:02 Go to previous messageGo to next message
Jörg Kiegeland is currently offline Jörg KiegelandFriend
Messages: 32
Registered: July 2009
Member
Ed,

> 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.

Thx, I didnt see those tabs..
Generating the model code with this error now produces code which can be
fixed quickly : I just had to remove a constant generated twice.
Re: inherit two properties with the same name [message #415738 is a reply to message #415710] Fri, 04 January 2008 16:20 Go to previous messageGo to next message
Philipp Kutter is currently offline Philipp KutterFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 Go to previous message
Philipp Kutter is currently offline Philipp KutterFriend
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?
Previous Topic:Import from Annotated Java into a different project
Next Topic:Duplicate method set generated
Goto Forum:
  


Current Time: Fri Mar 29 01:58:26 GMT 2024

Powered by FUDForum. Page generated in 0.23962 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top