Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Considering eSuperTypes of an EClass
Considering eSuperTypes of an EClass [message #1278656] Thu, 27 March 2014 16:58 Go to next message
Daniel Tahin is currently offline Daniel TahinFriend
Messages: 27
Registered: July 2013
Junior Member
Hello,

for an EClass in Ecore, more than one Superclasses can be specified. I would like to ask, if this multiple inheritance is exactly the same, as for C++? (Is there things, i should consider if i translate a class with multiple superclasses in a language other than Java or C++?)

Thank you in advance,
Daniel
Re: Considering eSuperTypes of an EClass [message #1278974 is a reply to message #1278656] Fri, 28 March 2014 04:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
Daniel,

Comments below.

On 27/03/2014 5:59 PM, Daniel Tahin wrote:
> Hello,
>
> for an EClass in Ecore, more than one Superclasses can be specified. I
> would like to ask, if this multiple inheritance is exactly the same,
> as for C++? (Is there things, i should consider if i translate a class
> with multiple superclasses in a language other than Java or C++?)
Yes and no. We try to make it mostly behave the same, but in the end,
there are implementation details that make it not exactly the same. In
particular, the first super EClass of an EClass is special because the
implementation class of that super EClass will be extended by the
implementation class of the EClass. In terms of dynamic models, that
means the first non-dynamic EClass recursively reachable via the first
super EClass in the inheritance chain will be instantiated as the base
implementation class; as a consequence, you can't dynamically extend an
abstract non-dynamic EClass because its implementation class will also
be abstract and you can't instantiate an abstract class in Java. In
terms of generated models, that means all the additional super EClasses
are like mix-ins and those interfaces need to be reimplemented in the
derived class; as a consequence, it's best order the super EClasses so
that the largest, most significant implementation is reused. Of course
the generator will happily generate a full implementation for you no
matter the order, but if there are hand written changes, those will need
to be hand duplicated in the mix-in case.
>
> Thank you in advance,
> Daniel
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Considering eSuperTypes of an EClass [message #1284624 is a reply to message #1278974] Fri, 04 April 2014 17:51 Go to previous messageGo to next message
Daniel Tahin is currently offline Daniel TahinFriend
Messages: 27
Registered: July 2013
Junior Member
Ed Merks wrote on Fri, 28 March 2014 00:22
Daniel,

Comments below.

On 27/03/2014 5:59 PM, Daniel Tahin wrote:
> Hello,
>
> for an EClass in Ecore, more than one Superclasses can be specified. I
> would like to ask, if this multiple inheritance is exactly the same,
> as for C++? (Is there things, i should consider if i translate a class
> with multiple superclasses in a language other than Java or C++?)
Yes and no. We try to make it mostly behave the same, but in the end,
there are implementation details that make it not exactly the same. In
particular, the first super EClass of an EClass is special because the
implementation class of that super EClass will be extended by the
implementation class of the EClass. In terms of dynamic models, that
means the first non-dynamic EClass recursively reachable via the first
super EClass in the inheritance chain will be instantiated as the base
implementation class; as a consequence, you can't dynamically extend an
abstract non-dynamic EClass because its implementation class will also
be abstract and you can't instantiate an abstract class in Java. In
terms of generated models, that means all the additional super EClasses
are like mix-ins and those interfaces need to be reimplemented in the
derived class; as a consequence, it's best order the super EClasses so
that the largest, most significant implementation is reused. Of course
the generator will happily generate a full implementation for you no
matter the order, but if there are hand written changes, those will need
to be hand duplicated in the mix-in case.
>
> Thank you in advance,
> Daniel
>




Thank you for the answer.


If i correct understand this is the way, how Java deals with multiple superclasses. (Yes in Java we can EXTEND only 1 superclass and IMPLEMENT many interface-classes.)
But for instance in C++ we can extend many superclasses (and there is no concept of interface classes like in Java).
If i have to transform a class with more then one superclass, i should do this in the same way, like in your description?
Or is the multiple inheritance the same as the generalisation in UML? (So i can treat the superclasses as a "collection" of attributes/functions, that a subclass inherit, and can override?)
I realised e.g., that in a class-hierarchy (super/subclasses) only 1 attribute (with ID=true) can exist. Are there maybe some other things like this?

Thank you again,
Daniel
Re: Considering eSuperTypes of an EClass [message #1284995 is a reply to message #1284624] Sat, 05 April 2014 03:35 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
Daniel,

Comments below.

On 04/04/2014 7:51 PM, Daniel Tahin wrote:
> Ed Merks wrote on Fri, 28 March 2014 00:22
>> Daniel,
>>
>> Comments below.
>>
>> On 27/03/2014 5:59 PM, Daniel Tahin wrote:
>> > Hello,
>> >
>> > for an EClass in Ecore, more than one Superclasses can be
>> specified. I > would like to ask, if this multiple inheritance is
>> exactly the same, > as for C++? (Is there things, i should consider
>> if i translate a class > with multiple superclasses in a language
>> other than Java or C++?)
>> Yes and no. We try to make it mostly behave the same, but in the
>> end, there are implementation details that make it not exactly the
>> same. In particular, the first super EClass of an EClass is special
>> because the implementation class of that super EClass will be
>> extended by the implementation class of the EClass. In terms of
>> dynamic models, that means the first non-dynamic EClass recursively
>> reachable via the first super EClass in the inheritance chain will be
>> instantiated as the base implementation class; as a consequence, you
>> can't dynamically extend an abstract non-dynamic EClass because its
>> implementation class will also be abstract and you can't instantiate
>> an abstract class in Java. In terms of generated models, that means
>> all the additional super EClasses are like mix-ins and those
>> interfaces need to be reimplemented in the derived class; as a
>> consequence, it's best order the super EClasses so that the largest,
>> most significant implementation is reused. Of course the generator
>> will happily generate a full implementation for you no matter the
>> order, but if there are hand written changes, those will need to be
>> hand duplicated in the mix-in case.
>> >
>> > Thank you in advance,
>> > Daniel
>> >
>
>
>
>
> Thank you for the answer.
>
>
> If i correct understand this is the way, how Java deals with multiple
> superclasses. (Yes in Java we can EXTEND only 1 superclass and
> IMPLEMENT many interface-classes.)
Yes, ultimately we generate Java code from a model...
> But for instance in C++ we can extend many superclasses (and there is
> no concept of interface classes like in Java).
Yes, C++ is different.
> If i have to transform a class with more then one superclass, i should
> do this in the same way, like in your description?
What do you mean by a "class" here? A C++ class?
> Or is the multiple inheritance the same as the generalisation in UML?
I don't think commenting on UML will help clarify how Ecore works...
Then we'd have to deal with a Java class verses a C++ class verses a UML
class verses an Ecore class. They're all a little different, with UML
being the least well defined semantically, so let's not go there.
> (So i can treat the superclasses as a "collection" of
> attributes/functions, that a subclass inherit, and can override?)
Think of an EClasses features like Java fields, you cannot override
them, so a derived class is a collection of features and those feature
names must be unique. Only operations are like functions/methods and
can be overridden in a subclass.
> I realised e.g., that in a class-hierarchy (super/subclasses) only 1
> attribute (with ID=true) can exist. Are there maybe some other things
> like this?
The union of the features must have unique names.
>
> Thank you again,
> Daniel
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[oomph] let users open custom setup file
Next Topic:[Xcore] Accessing a SuppressedGetVisibility feature in operation w/ Xtend
Goto Forum:
  


Current Time: Fri Apr 26 03:58:41 GMT 2024

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

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

Back to the top