Home » Modeling » EMF » The definitive truth about multiple inheritance
| The definitive truth about multiple inheritance [message #431103] |
Sun, 28 June 2009 21:43  |
Eclipse User |
|
|
|
Originally posted by: gvauvert.gmail.com
Happy to join the team of EMF's users !
After many searches, I have found no clear answer to my basic question
about multiple inheritance.
The EMF documentation
( http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/references/overview/EMF.html
, chapter "EMF developper guide", section "EMF developper guide",
subsection "EMF Framework Programmer's Guide") saids :
"As in Java itself, multiple interface inheritance is supported, but
each EMF class can only extend one implementation base class. Therefore,
when we have a model with multiple inheritance, we need to identify
which of the multiple bases should be used as the implementation base
class. The others will then be simply treated as mixin interfaces, with
their implementations generated into the derived implementation class."
The example shows a model with a class [SchoolBook] that inherits
<<extends>> [Book] and that inherits [Asset]; this class should be
implemented by extending (Java) the class Book and implenting the
methods of the class Asset by copying them from Asset.
I tried to apply that to my model :
D inherits from A that inherits from Action, and C that inherits from Class.
The implementation of class D does provide implementations for methods
found in A and C, but does provide no implementations for methods coming
from inheritance of the class not extended (Action or Class depending on
the class (C or A) that D extends).
Have I missed something ?
If not, why isn't it possible for EMF to automatically generate the
"good" implementation ?
What can I do to solve my problem ?
Thank you very much for clarify my knowledge ...
Guillaume Vauvert
http://www.ixmas.org
|
|
|
| Re: The definitive truth about multiple inheritance [message #431104 is a reply to message #431103] |
Sun, 28 June 2009 22:07  |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Guillaume,
Comments below.
Guillaume Vauvert wrote:
> Happy to join the team of EMF's users !
Welcome. :-)
>
> After many searches, I have found no clear answer to my basic question
> about multiple inheritance.
>
> The EMF documentation
> ( http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/references/overview/EMF.html
> , chapter "EMF developper guide", section "EMF developper guide",
> subsection "EMF Framework Programmer's Guide") saids :
>
> "As in Java itself, multiple interface inheritance is supported, but
> each EMF class can only extend one implementation base class.
> Therefore, when we have a model with multiple inheritance, we need to
> identify which of the multiple bases should be used as the
> implementation base class. The others will then be simply treated as
> mixin interfaces, with their implementations generated into the
> derived implementation class."
>
> The example shows a model with a class [SchoolBook] that inherits
> <<extends>> [Book] and that inherits [Asset]; this class should be
> implemented by extending (Java) the class Book and implenting the
> methods of the class Asset by copying them from Asset.
>
> I tried to apply that to my model :
> D inherits from A that inherits from Action, and C that inherits from
> Class.
> The implementation of class D does provide implementations for methods
> found in A and C, but does provide no implementations for methods
> coming from inheritance of the class not extended (Action or Class
> depending on the class (C or A) that D extends).
I keep reading this and it's making my brain hurt. Maybe you could draw
a picture or make explicit what methods you're talking about. Is D
inheriting from C or is it A that's doing that, or is the comma implying
that C inherits from Class but is otherwise unrelated?
>
> Have I missed something ?
So far it's probably me that's missed something.
> If not, why isn't it possible for EMF to automatically generate the
> "good" implementation ?
The point that is that if you consider the super types Y and Z of an
EClass X, XImpl will extend YImpl and will generate a clone of what's in
ZImpl. So it should indeed be possible to generate a complete
implementation.
> What can I do to solve my problem ?
Are you saying that's generated doesn't compile?
>
> Thank you very much for clarify my knowledge ...
>
> Guillaume Vauvert
> http://www.ixmas.org
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: The definitive truth about multiple inheritance [message #431127 is a reply to message #431104] |
Mon, 29 June 2009 20:37 |
| Eclipse User |
|
|
|
Originally posted by: gvauvert.gmail.com
Ed,
I will try to decrease your headache ...
> I keep reading this and it's making my brain hurt. Maybe you could draw
> a picture or make explicit what methods you're talking about. Is D
> inheriting from C or is it A that's doing that, or is the comma implying
> that C inherits from Class but is otherwise unrelated?
You are right : my explanation is more complex than what I want to describe.
So :
- A inherits from Action
- C inherits from Class
- D inherits from both A and C
So simple when it is clear !
The generated code :
- the class DImpl extends the class AImpl : it is OK.
- the class DImpl implements the interface D ; the interface D extends
the interface A and the interface C.
- the class DImpl inherits methods from AImpl : so it implements the
interface A;
- the class DImpl contains methods that are declared in the interface C ;
- BUT DImpl does not contain methods that are inherited by the
interface C from the interface Class.
So, the class DImpl should be declared abstract, because it does not
implements the methods inherited by the interface C that it should
implement.
> The point that is that if you consider the super types Y and Z of an
> EClass X, XImpl will extend YImpl and will generate a clone of what's in
> ZImpl. So it should indeed be possible to generate a complete
> implementation.
It is exactly what I expect. Instead, I get a partial implementation.
>> What can I do to solve my problem ?
> Are you saying that's generated doesn't compile?
Yes, it does not compile, because the class lacks some methods, those
from the class Class inherited by the interface C.
Do you see what is my problem now ?
And do you see a solution ... ?
Guillaume Vauvert
http://www.ixmas.org
|
|
|
| Re: The definitive truth about multiple inheritance [message #431132 is a reply to message #431127] |
Mon, 29 June 2009 23:02 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Guillaume,
Comments below...
Guillaume Vauvert wrote:
> Ed,
>
> I will try to decrease your headache ...
>> I keep reading this and it's making my brain hurt. Maybe you could
>> draw a picture or make explicit what methods you're talking about.
>> Is D inheriting from C or is it A that's doing that, or is the comma
>> implying that C inherits from Class but is otherwise unrelated?
> You are right : my explanation is more complex than what I want to
> describe.
> So :
> - A inherits from Action
> - C inherits from Class
Class is a bit of a confusing name.
> - D inherits from both A and C
> So simple when it is clear !
>
> The generated code :
> - the class DImpl extends the class AImpl : it is OK.
> - the class DImpl implements the interface D ; the interface D extends
> the interface A and the interface C.
> - the class DImpl inherits methods from AImpl : so it implements
> the interface A;
> - the class DImpl contains methods that are declared in the
> interface C ;
> - BUT DImpl does not contain methods that are inherited by the
> interface C from the interface Class.
Did you declare all these methods in Ecore's version of Class? I'm
suspicious about that name...
> So, the class DImpl should be declared abstract, because it does not
> implements the methods inherited by the interface C that it should
> implement.
I have this suspicion that perhaps Class has methods in Java, that you
didn't actually declare as EOperation in the Ecore wrapper...
>
>> The point that is that if you consider the super types Y and Z of an
>> EClass X, XImpl will extend YImpl and will generate a clone of what's
>> in ZImpl. So it should indeed be possible to generate a complete
>> implementation.
> It is exactly what I expect. Instead, I get a partial implementation.
You've not been entirely clear if you're talking about EOperations or
EStructuralFeatures, which leads to my suspicion about what you declared
in Ecore verses what's there in Java....
>
>>> What can I do to solve my problem ?
>> Are you saying that's generated doesn't compile?
> Yes, it does not compile, because the class lacks some methods, those
> from the class Class inherited by the interface C.
>
> Do you see what is my problem now ?
Yes, but I'm more suspicious that there's something you've not stated
explicitly. EMF won't know to implement a method if there's no
EOperation declared for it in Class. I'm pretty sure if you specify the
right EOperations, there's at least be stub methods generated.
> And do you see a solution ... ?
I'd suggest you provide an example model that I can use to reproduce the
problem. Then I can tell you if the problem is your model or in the
framework.
>
> Guillaume Vauvert
> http://www.ixmas.org
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: The definitive truth about multiple inheritance [message #431222 is a reply to message #431132] |
Thu, 02 July 2009 21:36 |
| Eclipse User |
|
|
|
Originally posted by: gvauvert.gmail.com
Ed,
Ed Merks a écrit :
>> So :
>> - A inherits from Action
>> - C inherits from Class
> Class is a bit of a confusing name.
>> - D inherits from both A and C
>> So simple when it is clear !
>>
>> The generated code :
>> - the class DImpl extends the class AImpl : it is OK.
>> - the class DImpl implements the interface D ; the interface D extends
>> the interface A and the interface C.
>> - the class DImpl inherits methods from AImpl : so it implements
>> the interface A;
>> - the class DImpl contains methods that are declared in the
>> interface C ;
>> - BUT DImpl does not contain methods that are inherited by the
>> interface C from the interface Class.
> Did you declare all these methods in Ecore's version of Class? I'm
> suspicious about that name...
I am building a Modeling Language that extends UML.
I am using platform:/plugin/org.eclipse.uml2.uml/model/UML.core as model
of UML.
The metaclass Class (using ECore) declares the EOperation "ownedOperation".
In the generated class DImpl, I obtain a class that should contains the
implementation of getOwnedReception() (from the interface C). Instead, I
have a class DImpl that lacks this method ; so, Eclipse Java IDE saids :
"The type DImpl must implement the inherited abstract method
Class.getOwnedReception(String, EList<String>, EList<Type>)"
>> And do you see a solution ... ?
> I'd suggest you provide an example model that I can use to reproduce the
> problem. Then I can tell you if the problem is your model or in the
> framework.
Even if my example is exactly what I descrived before, I can provide it,
but how (future generations of newsgroups users must be able to see
the model !) ?
I feel the light closer ...
Thanks !
Guillaume Vauvert
http://www.ixmas.org
|
|
|
| Re: The definitive truth about multiple inheritance [message #431223 is a reply to message #431222] |
Thu, 02 July 2009 21:53 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Guillaume,
The UML project has an extended GenModel and has specialized some of the
templates for generating the code. Perhaps that's part of what's going
on...
I do have UML installed, so if you export to a zip the project with your
model, I should be able to reproduce what you're seeing and determine if
there's a bug in how EOperations are handled in a multiple inheritance
scenario...
I suspect that you need to use UML's extended GenModel if you extend the
UML model. I've added the UML2 newsgroup to the "to"list of the reply
for their comments about how one should extend UML2...
Guillaume Vauvert wrote:
> Ed,
>
> Ed Merks a écrit :
>>> So :
>>> - A inherits from Action
>>> - C inherits from Class
>> Class is a bit of a confusing name.
>>> - D inherits from both A and C
>>> So simple when it is clear !
>>>
>>> The generated code :
>>> - the class DImpl extends the class AImpl : it is OK.
>>> - the class DImpl implements the interface D ; the interface D
>>> extends the interface A and the interface C.
>>> - the class DImpl inherits methods from AImpl : so it implements
>>> the interface A;
>>> - the class DImpl contains methods that are declared in the
>>> interface C ;
>>> - BUT DImpl does not contain methods that are inherited by the
>>> interface C from the interface Class.
>> Did you declare all these methods in Ecore's version of Class? I'm
>> suspicious about that name...
> I am building a Modeling Language that extends UML.
> I am using platform:/plugin/org.eclipse.uml2.uml/model/UML.core as
> model of UML.
> The metaclass Class (using ECore) declares the EOperation
> "ownedOperation".
> In the generated class DImpl, I obtain a class that should contains
> the implementation of getOwnedReception() (from the interface C).
> Instead, I have a class DImpl that lacks this method ; so, Eclipse
> Java IDE saids :
> "The type DImpl must implement the inherited abstract method
> Class.getOwnedReception(String, EList<String>, EList<Type>)"
>
>>> And do you see a solution ... ?
>> I'd suggest you provide an example model that I can use to reproduce
>> the problem. Then I can tell you if the problem is your model or in
>> the framework.
> Even if my example is exactly what I descrived before, I can provide
> it, but how (future generations of newsgroups users must be able to
> see the model !) ?
>
> I feel the light closer ...
>
> Thanks !
>
> Guillaume Vauvert
> http://www.ixmas.org
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: The definitive truth about multiple inheritance [message #431234 is a reply to message #431223] |
Sat, 04 July 2009 09:10 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040407050404070808060007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Guillaume,
This definitely sounds UML specific. Try using the text editor to
replace this
xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"
with this
xmlns:genmodel="http://www.eclipse.org/uml2/2.2.0/GenModel"
I.e., trying changing it to be the UML project's derived GenModel. That
should ensure that UML's generator specializations kick in.
Also, try avoid doing reply-all on newsgroup postings so they don't also
end up in my personal in-box. :-P
Try to avoid doing reply-all
Guillaume Vauvert wrote:
> Hello MDT/UML2 users,
>
> I had a question on model code generation, but, thanks to Ed, I now
> believe that the question is more MDT/UML2 specific.
>
> The model contains a class TempleteableActivityNode that inherits from
> both the class Templeteable and the class ActivityNode. The class
> ActivityNode contains the attribute "incoming" with multiplicty 0..* .
>
> This attribute "incoming" is implemented in ActivityNodeImpl as :
> public EList<ActivityEdge> getIncomings()
> and as :
> public ActivityEdge getIncoming(String name)
>
> In the generated model code class TempleteableActivityNode, the method
> "public EList<ActivityEdge> getIncomings()" is implemented, but not
> the method "public ActivityEdge getIncoming(String name)", what leads
> to an error :
> "The type TempleteableActivityNodeImpl must implement the inherited
> abstract method ActivityNode.getIncoming(String)"
>
> Have you an idea of where I am wrong ?
>
> Thank you ...
>
> Guillaume Vauvert
>
> Thanks you Ed for your help : you guide me to investigate more deeply
> my problem.
>
>
> Ed Merks a
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: The definitive truth about multiple inheritance [message #431235 is a reply to message #431223] |
Sat, 04 July 2009 10:38 |
| Eclipse User |
|
|
|
Originally posted by: gvauvert.gmail.com
Hello MDT/UML2 users,
I had a question on model code generation, but, thanks to Ed, I now
believe that the question is more MDT/UML2 specific.
The model contains a class TempleteableActivityNode that inherits from
both the class Templeteable and the class ActivityNode. The class
ActivityNode contains the attribute "incoming" with multiplicty 0..* .
This attribute "incoming" is implemented in ActivityNodeImpl as :
public EList<ActivityEdge> getIncomings()
and as :
public ActivityEdge getIncoming(String name)
In the generated model code class TempleteableActivityNode, the method
"public EList<ActivityEdge> getIncomings()" is implemented, but not the
method "public ActivityEdge getIncoming(String name)", what leads to an
error :
"The type TempleteableActivityNodeImpl must implement the inherited
abstract method ActivityNode.getIncoming(String)"
Have you an idea of where I am wrong ?
Thank you ...
Guillaume Vauvert
Thanks you Ed for your help : you guide me to investigate more deeply
my problem.
Ed Merks a écrit :
> Guillaume,
>
> The UML project has an extended GenModel and has specialized some of
the templates for generating the code. Perhaps that's part of what's
going on...
> I do have UML installed, so if you export to a zip the project with
your model, I should be able to reproduce what you're seeing and
determine if there's a bug in how EOperations are handled in a multiple
inheritance scenario...
>
> I suspect that you need to use UML's extended GenModel if you extend
the UML model. I've added the UML2 newsgroup to the "to"list of the
reply for their comments about how one should extend UML2...
>
>
> Guillaume Vauvert wrote:
>> Ed,
>>
>> Ed Merks a écrit :
>>>> So :
>>>> - A inherits from Action
>>>> - C inherits from Class
>>> Class is a bit of a confusing name.
>>>> - D inherits from both A and C
>>>> So simple when it is clear !
>>>>
>>>> The generated code :
>>>> - the class DImpl extends the class AImpl : it is OK.
>>>> - the class DImpl implements the interface D ; the interface D
extends the interface A and the interface C.
>>>> - the class DImpl inherits methods from AImpl : so it
implements the interface A;
>>>> - the class DImpl contains methods that are declared in the
interface C ;
>>>> - BUT DImpl does not contain methods that are inherited by the
interface C from the interface Class.
>>> Did you declare all these methods in Ecore's version of Class? I'm
suspicious about that name...
>> I am building a Modeling Language that extends UML.
>> I am using platform:/plugin/org.eclipse.uml2.uml/model/UML.core as
model of UML.
>> The metaclass Class (using ECore) declares the EOperation
"ownedOperation".
>> In the generated class DImpl, I obtain a class that should contains
the implementation of getOwnedReception() (from the interface C).
Instead, I have a class DImpl that lacks this method ; so, Eclipse Java
IDE saids :
>> "The type DImpl must implement the inherited abstract method
Class.getOwnedReception(String, EList<String>, EList<Type>)"
>>
>>>> And do you see a solution ... ?
>>> I'd suggest you provide an example model that I can use to
reproduce the problem. Then I can tell you if the problem is your model
or in the framework.
>> Even if my example is exactly what I descrived before, I can provide
it, but how (future generations of newsgroups users must be able to see
the model !) ?
>>
>> I feel the light closer ...
>>
>> Thanks !
>>
>> Guillaume Vauvert
>> http://www.ixmas.org
|
|
|
Goto Forum:
Current Time: Tue Apr 23 06:16:58 GMT 2024
Powered by FUDForum. Page generated in 0.04338 seconds |
] 
Search
Help
Register
Login
Home
