Home » Modeling » EMF » Abstract Classes
| | | | |
Re: Abstract Classes [message #417071 is a reply to message #417068] |
Mon, 25 February 2008 20:16 |
Martin Tauber 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 |
Ed Merks Messages: 33163 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 |
Martin Tauber 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() {}
>>>>>> }
|
|
|
Goto Forum:
Current Time: Sat Jun 15 20:54:58 GMT 2024
Powered by FUDForum. Page generated in 0.04287 seconds
|