|
| Re: [Helios] why eAllsuperTypes() doesn't return EObject anymore ? [message #546409 is a reply to message #546400] |
Mon, 12 July 2010 16:31   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tristan,
Comments below.
Tristan FAURE wrote:
> Hi !
> I have some migration problems with Helios new API. And i see the
> method :
> EClass.getEAllSuperTypes() (for an UML Eclass) doesn't return EObject
> anymore. Does it exist some documentation about this modification ? Or
> Do i Have made a dream about this ^^ ?
For 2.6 we added support for EObject.eInvoke. This requires an eInvoke
method to be generated for any model that defines operations and enables
this support (GenModel's Reflective Operations set to true). We wanted
to enable this for Ecore itself and for UML, but we didn't want the
generated eInvoke method to have to cover the significantly large number
of operations in EObject itself nor to have to introduce many more
constants for these cases. It should never be necessary to extend
EObject explicitly in the model in the first place and most models don't
do it. The fact that EModelElement did anyway was an unfortunate choice
that up until 2.6 had no significant negative impact. For 2.6 we
decided to remove it. A few clients noticed, but in all cases it helped
highlight the fact that their design made their logic work only for
models that explicitly extend EObject, which in all cases so far has
proven to be a design oversight, i.e., although clients were impacted,
they generalized their code and made it more generally applicable to all
models, not just ones explicitly extending EObject. Likely you fall
into this category as well, or perhaps you just have an inquiring mind...
>
> Regards
> Tristan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Helios] why eAllsuperTypes() doesn't return EObject anymore ? [message #546423 is a reply to message #546409] |
Mon, 12 July 2010 16:39 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Hi ed thank your for your answer.
It's just we have designed some code generation based on EObject
matching and it doesn't work anymore. We will take a look and ask the
developers of the generation tool (obeo ;) )
Regards
Tristan FAURE
Le 12/07/2010 18:31, Ed Merks a écrit :
> Tristan,
>
> Comments below.
>
> Tristan FAURE wrote:
>> Hi !
>> I have some migration problems with Helios new API. And i see the
>> method :
>> EClass.getEAllSuperTypes() (for an UML Eclass) doesn't return EObject
>> anymore. Does it exist some documentation about this modification ?
>> Or Do i Have made a dream about this ^^ ?
> For 2.6 we added support for EObject.eInvoke. This requires an
> eInvoke method to be generated for any model that defines operations
> and enables this support (GenModel's Reflective Operations set to
> true). We wanted to enable this for Ecore itself and for UML, but we
> didn't want the generated eInvoke method to have to cover the
> significantly large number of operations in EObject itself nor to have
> to introduce many more constants for these cases. It should never be
> necessary to extend EObject explicitly in the model in the first place
> and most models don't do it. The fact that EModelElement did anyway
> was an unfortunate choice that up until 2.6 had no significant
> negative impact. For 2.6 we decided to remove it. A few clients
> noticed, but in all cases it helped highlight the fact that their
> design made their logic work only for models that explicitly extend
> EObject, which in all cases so far has proven to be a design
> oversight, i.e., although clients were impacted, they generalized
> their code and made it more generally applicable to all models, not
> just ones explicitly extending EObject. Likely you fall into this
> category as well, or perhaps you just have an inquiring mind...
>>
>> Regards
>> Tristan
|
|
|
| Re: [Helios] why eAllsuperTypes() doesn't return EObject anymore ? [message #546447 is a reply to message #546423] |
Mon, 12 July 2010 19:30 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Tristan
The change is certainly surprising but actually it is also highly
aligned to MOF and UML.
A user meta-model is defined by the user with no OMG imposed methods. In
particular Element::getMetaClass() is only present if the user chooses
to generalize Element. Perhaps Ecore could provide an optional EElement
so that eClass() is available in user models.
It is only when OCL defines OclAny as a type to which all types conform
that an opportunity for arbitrary reflection is introduced by
OclAny::oclType() whose definition is unsatisfactory. It has been
revised in OCL 2.0, and again in OCL 2.2. Another revision is pending,
which MDT/OCL might manage to implement.
Regards
Ed Willink
On 12/07/2010 17:39, Tristan FAURE wrote:
> Hi ed thank your for your answer.
> It's just we have designed some code generation based on EObject
> matching and it doesn't work anymore. We will take a look and ask the
> developers of the generation tool (obeo ;) )
>
> Regards
> Tristan FAURE
>
> Le 12/07/2010 18:31, Ed Merks a écrit :
>> Tristan,
>>
>> Comments below.
>>
>> Tristan FAURE wrote:
>>> Hi !
>>> I have some migration problems with Helios new API. And i see the
>>> method :
>>> EClass.getEAllSuperTypes() (for an UML Eclass) doesn't return EObject
>>> anymore. Does it exist some documentation about this modification ?
>>> Or Do i Have made a dream about this ^^ ?
>> For 2.6 we added support for EObject.eInvoke. This requires an eInvoke
>> method to be generated for any model that defines operations and
>> enables this support (GenModel's Reflective Operations set to true).
>> We wanted to enable this for Ecore itself and for UML, but we didn't
>> want the generated eInvoke method to have to cover the significantly
>> large number of operations in EObject itself nor to have to introduce
>> many more constants for these cases. It should never be necessary to
>> extend EObject explicitly in the model in the first place and most
>> models don't do it. The fact that EModelElement did anyway was an
>> unfortunate choice that up until 2.6 had no significant negative
>> impact. For 2.6 we decided to remove it. A few clients noticed, but in
>> all cases it helped highlight the fact that their design made their
>> logic work only for models that explicitly extend EObject, which in
>> all cases so far has proven to be a design oversight, i.e., although
>> clients were impacted, they generalized their code and made it more
>> generally applicable to all models, not just ones explicitly extending
>> EObject. Likely you fall into this category as well, or perhaps you
>> just have an inquiring mind...
>>>
>>> Regards
>>> Tristan
|
|
|
| Re: [Helios] why eAllsuperTypes() doesn't return EObject anymore? [message #547972 is a reply to message #546423] |
Tue, 20 July 2010 09:57 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Tristan,
either you use Acceleo 2.X, and the "EObject" type in the template should
always work even if you have no inheritance in your Ecore model, or you use
Acceleo 3.x and then OCLAny is the right type to use.
Cheers,
Cédric
Tristan FAURE wrote:
> Hi ed thank your for your answer.
> It's just we have designed some code generation based on EObject
> matching and it doesn't work anymore. We will take a look and ask the
> developers of the generation tool (obeo ;) )
>
> Regards
> Tristan FAURE
>
> Le 12/07/2010 18:31, Ed Merks a écrit :
>> Tristan,
>>
>> Comments below.
>>
>> Tristan FAURE wrote:
>>> Hi !
>>> I have some migration problems with Helios new API. And i see the
>>> method :
>>> EClass.getEAllSuperTypes() (for an UML Eclass) doesn't return EObject
>>> anymore. Does it exist some documentation about this modification ?
>>> Or Do i Have made a dream about this ^^ ?
>> For 2.6 we added support for EObject.eInvoke. This requires an
>> eInvoke method to be generated for any model that defines operations
>> and enables this support (GenModel's Reflective Operations set to
>> true). We wanted to enable this for Ecore itself and for UML, but we
>> didn't want the generated eInvoke method to have to cover the
>> significantly large number of operations in EObject itself nor to have
>> to introduce many more constants for these cases. It should never be
>> necessary to extend EObject explicitly in the model in the first place
>> and most models don't do it. The fact that EModelElement did anyway
>> was an unfortunate choice that up until 2.6 had no significant
>> negative impact. For 2.6 we decided to remove it. A few clients
>> noticed, but in all cases it helped highlight the fact that their
>> design made their logic work only for models that explicitly extend
>> EObject, which in all cases so far has proven to be a design
>> oversight, i.e., although clients were impacted, they generalized
>> their code and made it more generally applicable to all models, not
>> just ones explicitly extending EObject. Likely you fall into this
>> category as well, or perhaps you just have an inquiring mind...
>>>
>>> Regards
>>> Tristan
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
Powered by
FUDForum. Page generated in 0.05712 seconds
] 
Search
Help
Register
Login
Home
