Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Abstract Classes
Abstract Classes [message #417044] Sun, 24 February 2008 15:40 Go to next message
Martin Tauber is currently offline Martin TauberFriend
Messages: 122
Registered: July 2009
Senior Member
I would like to create an emf model which should look like this. The
idea is that I have different types of children, but code which is not
interested in this speciallity. I don't want to craete a switch in these
cases ...

class Container {
/**
* model type="SpecialChild" opposite="container"
*/
List getSpecialChildren() {}
}

abstract class Child {
Container getContainer();
}

class specialChild extends Child {
/**
* model opposite="specialChildren"
*/
Container getContainer() {}
}
Re: Abstract Classes [message #417045 is a reply to message #417044] Sun, 24 February 2008 17:50 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

I'm not sure what you question is though. You can certainly do what you
outline below. You could make getContainer be an EOperation in Child,
i.e., define @model kind="operation" for it. I assume you intended all
the things below to be interfaces...


Martin Tauber wrote:
> I would like to create an emf model which should look like this. The
> idea is that I have different types of children, but code which is not
> interested in this speciallity. I don't want to craete a switch in
> these cases ...
>
> class Container {
> /**
> * model type="SpecialChild" opposite="container"
> */
> List getSpecialChildren() {}
> }
>
> abstract class Child {
> Container getContainer();
> }
>
> class specialChild extends Child {
> /**
> * model opposite="specialChildren"
> */
> Container getContainer() {}
> }


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Abstract Classes [message #417065 is a reply to message #417045] Mon, 25 February 2008 17:44 Go to previous messageGo to next message
Martin Tauber is currently offline Martin TauberFriend
Messages: 122
Registered: July 2009
Senior Member
Ed,

first of all I'm always very impressed about how quick you respond.
Thank you very much for that, this really makes the my work much easier!

The example below is actually the way I would have written the classes,
without using emf (ok except of course the java comments). I forgot my
EMF book at home so I'll go out to the net to find out what you mean by
operation ...

Thanks for your help!
Martin

Ed Merks wrote:
> Martin,
>
> I'm not sure what you question is though. You can certainly do what you
> outline below. You could make getContainer be an EOperation in Child,
> i.e., define @model kind="operation" for it. I assume you intended all
> the things below to be interfaces...
>
>
> Martin Tauber wrote:
>> I would like to create an emf model which should look like this. The
>> idea is that I have different types of children, but code which is not
>> interested in this speciallity. I don't want to craete a switch in
>> these cases ...
>>
>> class Container {
>> /**
>> * model type="SpecialChild" opposite="container"
>> */
>> List getSpecialChildren() {}
>> }
>>
>> abstract class Child {
>> Container getContainer();
>> }
>>
>> class specialChild extends Child {
>> /**
>> * model opposite="specialChildren"
>> */
>> Container getContainer() {}
>> }
Re: Abstract Classes [message #417066 is a reply to message #417045] Mon, 25 February 2008 18:04 Go to previous messageGo to next message
Martin Tauber is currently offline Martin TauberFriend
Messages: 122
Registered: July 2009
Senior Member
Hm - I didn't find anything on EOperation in the internet ... I created
an example and looked at the generated source. It doesn't look like what
I want. There code is generated for the Child class (which I have to
complete) bt this is not what I want. I want Child to be abstract which
has an unimplemented method getContents() which I then implement in the
class SpecialChild ...

Regards
Martin

Ed Merks wrote:
> Martin,
>
> I'm not sure what you question is though. You can certainly do what you
> outline below. You could make getContainer be an EOperation in Child,
> i.e., define @model kind="operation" for it. I assume you intended all
> the things below to be interfaces...
>
>
> Martin Tauber wrote:
>> I would like to create an emf model which should look like this. The
>> idea is that I have different types of children, but code which is not
>> interested in this speciallity. I don't want to craete a switch in
>> these cases ...
>>
>> class Container {
>> /**
>> * model type="SpecialChild" opposite="container"
>> */
>> List getSpecialChildren() {}
>> }
>>
>> abstract class Child {
>> Container getContainer();
>> }
>>
>> class specialChild extends Child {
>> /**
>> * model opposite="specialChildren"
>> */
>> Container getContainer() {}
>> }
Re: Abstract Classes [message #417068 is a reply to message #417066] Mon, 25 February 2008 18:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

On the interface for the Child, you'd specify @model abstract="true".
Did you at least get it to include an EOperation? It will generate a
body that throws an exception, but you could change that to make it
abstract instead (and change @generated to @generated NOT to make sure
it stays that way). Note that a good way to reverse engineer the @model
annotations is to create an Ecore model and generate the code for it,
which will also generated the @model annotations needed to get that same
Ecore back...


Martin Tauber wrote:
> Hm - I didn't find anything on EOperation in the internet ... I
> created an example and looked at the generated source. It doesn't look
> like what I want. There code is generated for the Child class (which I
> have to complete) bt this is not what I want. I want Child to be
> abstract which has an unimplemented method getContents() which I then
> implement in the class SpecialChild ...
>
> Regards
> Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> I'm not sure what you question is though. You can certainly do what
>> you outline below. You could make getContainer be an EOperation in
>> Child, i.e., define @model kind="operation" for it. I assume you
>> intended all the things below to be interfaces...
>>
>>
>> Martin Tauber wrote:
>>> I would like to create an emf model which should look like this. The
>>> idea is that I have different types of children, but code which is
>>> not interested in this speciallity. I don't want to craete a switch
>>> in these cases ...
>>>
>>> class Container {
>>> /**
>>> * model type="SpecialChild" opposite="container"
>>> */
>>> List getSpecialChildren() {}
>>> }
>>>
>>> abstract class Child {
>>> Container getContainer();
>>> }
>>>
>>> class specialChild extends Child {
>>> /**
>>> * model opposite="specialChildren"
>>> */
>>> Container getContainer() {}
>>> }


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Abstract Classes [message #417071 is a reply to message #417068] Mon, 25 February 2008 20:16 Go to previous messageGo to next message
Martin Tauber is currently offline Martin TauberFriend
Messages: 122
Registered: July 2009
Senior Member
Ed,

I'm still don't know what EOperation is ... Nevertheless, as I
understand you I should overide the generated Method and change the
comment to generated NOT. But what I actually want is that no code for
the method getContainers() is in the ChildImpl.java. This is what
actually should make it abstract. Does EOperation help me there?

Thanks
Martin

Ed Merks wrote:
> Martin,
>
> On the interface for the Child, you'd specify @model abstract="true".
> Did you at least get it to include an EOperation? It will generate a
> body that throws an exception, but you could change that to make it
> abstract instead (and change @generated to @generated NOT to make sure
> it stays that way). Note that a good way to reverse engineer the @model
> annotations is to create an Ecore model and generate the code for it,
> which will also generated the @model annotations needed to get that same
> Ecore back...
>
>
> Martin Tauber wrote:
>> Hm - I didn't find anything on EOperation in the internet ... I
>> created an example and looked at the generated source. It doesn't look
>> like what I want. There code is generated for the Child class (which I
>> have to complete) bt this is not what I want. I want Child to be
>> abstract which has an unimplemented method getContents() which I then
>> implement in the class SpecialChild ...
>>
>> Regards
>> Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> I'm not sure what you question is though. You can certainly do what
>>> you outline below. You could make getContainer be an EOperation in
>>> Child, i.e., define @model kind="operation" for it. I assume you
>>> intended all the things below to be interfaces...
>>>
>>>
>>> Martin Tauber wrote:
>>>> I would like to create an emf model which should look like this. The
>>>> idea is that I have different types of children, but code which is
>>>> not interested in this speciallity. I don't want to craete a switch
>>>> in these cases ...
>>>>
>>>> class Container {
>>>> /**
>>>> * model type="SpecialChild" opposite="container"
>>>> */
>>>> List getSpecialChildren() {}
>>>> }
>>>>
>>>> abstract class Child {
>>>> Container getContainer();
>>>> }
>>>>
>>>> class specialChild extends Child {
>>>> /**
>>>> * model opposite="specialChildren"
>>>> */
>>>> Container getContainer() {}
>>>> }
Re: Abstract Classes [message #417072 is a reply to message #417071] Mon, 25 February 2008 20:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

Comments below.

Martin Tauber wrote:
> Ed,
>
> I'm still don't know what EOperation is ...
If you open a .ecore file and right click on an EClass, you'll see you
can create, among other things, an EAttribute, and EReference, or an
EOperation. EAttribute and EReference are both EStructuralFeatures and
their closest Java analog is the field of a class. I.e., they
correspond to data fields for which variables and accessor methods are
generate. An EOperation's closest Java analog is a method of a
class/interface. EMF will generate a corresponding method in the
interface, and a stub implementation in the class.
> Nevertheless, as I understand you I should overide the generated
> Method and change the comment to generated NOT. But what I actually
> want is that no code for the method getContainers() is in the
> ChildImpl.java.
Since the generator will generate a stub method even if the EClass is
abstract, the best way to achieve the equivalent goal is to change that
stub to be abstract.
> This is what actually should make it abstract.
An abstract method declaration is just a more verbose way to do the same
thing.
> Does EOperation help me there?
The point of ensuring you end up with an EOperation within the Child
EClass is to avoid generating fields for storage, as well as additional
accessor methods, like a setter.
>
> Thanks
> Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> On the interface for the Child, you'd specify @model
>> abstract="true". Did you at least get it to include an EOperation?
>> It will generate a body that throws an exception, but you could
>> change that to make it abstract instead (and change @generated to
>> @generated NOT to make sure it stays that way). Note that a good way
>> to reverse engineer the @model annotations is to create an Ecore
>> model and generate the code for it, which will also generated the
>> @model annotations needed to get that same Ecore back...
>>
>>
>> Martin Tauber wrote:
>>> Hm - I didn't find anything on EOperation in the internet ... I
>>> created an example and looked at the generated source. It doesn't
>>> look like what I want. There code is generated for the Child class
>>> (which I have to complete) bt this is not what I want. I want Child
>>> to be abstract which has an unimplemented method getContents() which
>>> I then implement in the class SpecialChild ...
>>>
>>> Regards
>>> Martin
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> I'm not sure what you question is though. You can certainly do
>>>> what you outline below. You could make getContainer be an
>>>> EOperation in Child, i.e., define @model kind="operation" for it.
>>>> I assume you intended all the things below to be interfaces...
>>>>
>>>>
>>>> Martin Tauber wrote:
>>>>> I would like to create an emf model which should look like this.
>>>>> The idea is that I have different types of children, but code
>>>>> which is not interested in this speciallity. I don't want to
>>>>> craete a switch in these cases ...
>>>>>
>>>>> class Container {
>>>>> /**
>>>>> * model type="SpecialChild" opposite="container"
>>>>> */
>>>>> List getSpecialChildren() {}
>>>>> }
>>>>>
>>>>> abstract class Child {
>>>>> Container getContainer();
>>>>> }
>>>>>
>>>>> class specialChild extends Child {
>>>>> /**
>>>>> * model opposite="specialChildren"
>>>>> */
>>>>> Container getContainer() {}
>>>>> }


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Abstract Classes [message #417094 is a reply to message #417072] Tue, 26 February 2008 21:43 Go to previous message
Martin Tauber is currently offline Martin TauberFriend
Messages: 122
Registered: July 2009
Senior Member
Thanks Ed, I declared the imp class method as abstract. This is what I
wanted.

Regards
Martin

Ed Merks wrote:
> Martin,
>
> Comments below.
>
> Martin Tauber wrote:
>> Ed,
>>
>> I'm still don't know what EOperation is ...
> If you open a .ecore file and right click on an EClass, you'll see you
> can create, among other things, an EAttribute, and EReference, or an
> EOperation. EAttribute and EReference are both EStructuralFeatures and
> their closest Java analog is the field of a class. I.e., they
> correspond to data fields for which variables and accessor methods are
> generate. An EOperation's closest Java analog is a method of a
> class/interface. EMF will generate a corresponding method in the
> interface, and a stub implementation in the class.
>> Nevertheless, as I understand you I should overide the generated
>> Method and change the comment to generated NOT. But what I actually
>> want is that no code for the method getContainers() is in the
>> ChildImpl.java.
> Since the generator will generate a stub method even if the EClass is
> abstract, the best way to achieve the equivalent goal is to change that
> stub to be abstract.
>> This is what actually should make it abstract.
> An abstract method declaration is just a more verbose way to do the same
> thing.
>> Does EOperation help me there?
> The point of ensuring you end up with an EOperation within the Child
> EClass is to avoid generating fields for storage, as well as additional
> accessor methods, like a setter.
>>
>> Thanks
>> Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> On the interface for the Child, you'd specify @model
>>> abstract="true". Did you at least get it to include an EOperation?
>>> It will generate a body that throws an exception, but you could
>>> change that to make it abstract instead (and change @generated to
>>> @generated NOT to make sure it stays that way). Note that a good way
>>> to reverse engineer the @model annotations is to create an Ecore
>>> model and generate the code for it, which will also generated the
>>> @model annotations needed to get that same Ecore back...
>>>
>>>
>>> Martin Tauber wrote:
>>>> Hm - I didn't find anything on EOperation in the internet ... I
>>>> created an example and looked at the generated source. It doesn't
>>>> look like what I want. There code is generated for the Child class
>>>> (which I have to complete) bt this is not what I want. I want Child
>>>> to be abstract which has an unimplemented method getContents() which
>>>> I then implement in the class SpecialChild ...
>>>>
>>>> Regards
>>>> Martin
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> I'm not sure what you question is though. You can certainly do
>>>>> what you outline below. You could make getContainer be an
>>>>> EOperation in Child, i.e., define @model kind="operation" for it.
>>>>> I assume you intended all the things below to be interfaces...
>>>>>
>>>>>
>>>>> Martin Tauber wrote:
>>>>>> I would like to create an emf model which should look like this.
>>>>>> The idea is that I have different types of children, but code
>>>>>> which is not interested in this speciallity. I don't want to
>>>>>> craete a switch in these cases ...
>>>>>>
>>>>>> class Container {
>>>>>> /**
>>>>>> * model type="SpecialChild" opposite="container"
>>>>>> */
>>>>>> List getSpecialChildren() {}
>>>>>> }
>>>>>>
>>>>>> abstract class Child {
>>>>>> Container getContainer();
>>>>>> }
>>>>>>
>>>>>> class specialChild extends Child {
>>>>>> /**
>>>>>> * model opposite="specialChildren"
>>>>>> */
>>>>>> Container getContainer() {}
>>>>>> }
Previous Topic:EFeatureMapEntry
Next Topic:emf.ant.tasks.jar
Goto Forum:
  


Current Time: Thu Mar 28 22:22:42 GMT 2024

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

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

Back to the top