Home » Modeling » EMF » Dynamic EMF , instantiation of Super class
|
| Re: Dynamic EMF , instantiation of Super class [message #479506 is a reply to message #479505] |
Tue, 11 August 2009 10:50   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
Christophe Bouhier wrote:
> related to my previous question, how to enhance my model with a custom
> operation, I started to look at Dynamic EMF, which is actually very cool.
Yes, it kind of a cool surprise to learn that you don't need to generate
code and yet still have all the benefits of a strongly typed reflective
model.
>
> Now if I create an instance of a dynamicly created class with a super
> type set to an existing static ECore class. the features for the super
> class are obviously not set.
It's generally true (or should be) that when you create a instance of
any EClass that none of its features will be set.
> But let's say I have an instance of the same type as the super class,
> can I somehow copy-in the feature values with i.e. ECoreUtil?
Things like EcoreUtil.Copier can be used in pretty interesting ways.
Even without it, it's certainly possible to call
y.eSet(x.eGet(feature)) when x and y share the same features (i.e.,
features of the common super class). Of course if the feature is a
containment feature, the values will actually be removed from x and
added to y, so some careful thinking is in order...
>
> This would allow me to build an enhanced version of my existing (and
> populated) static model at runtime.
One could imagine a cross model Copier where you feed it an instance of
the base model and not only does it make a copy of it, but the copies
are actually instances of a derived (perhaps dynamic) model. The
getTarget methods of the Copier can be specialized for that purpose.
You might well be better off making your base model support decorations
though so that it can be decorated to enhance it rather than needed to
be extended (much like EModelElement supports EAnnotations for that
purpose).
>
> Thanx! Christophe
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF , instantiation of Super class [message #479536 is a reply to message #479506] |
Tue, 11 August 2009 13:12 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Ah yes, I'd like to order one copier like that please. :-)
Not sure about model decorations, the index of the EMF book, wasn't
either...
Now I think of it, In a dynamic model, instead of creating boiler plate
to access the features (Which I just did), could OCL be used on the
dynamic model? (As OCL , I assume the OCL implementation uses the
reflection API to get and check stuff).
Christophe
Ed Merks wrote:
> Christophe,
>
> Comments below.
>
>
> Christophe Bouhier wrote:
>> related to my previous question, how to enhance my model with a custom
>> operation, I started to look at Dynamic EMF, which is actually very cool.
> Yes, it kind of a cool surprise to learn that you don't need to generate
> code and yet still have all the benefits of a strongly typed reflective
> model.
>>
>> Now if I create an instance of a dynamicly created class with a super
>> type set to an existing static ECore class. the features for the super
>> class are obviously not set.
> It's generally true (or should be) that when you create a instance of
> any EClass that none of its features will be set.
>> But let's say I have an instance of the same type as the super class,
>> can I somehow copy-in the feature values with i.e. ECoreUtil?
> Things like EcoreUtil.Copier can be used in pretty interesting ways.
> Even without it, it's certainly possible to call
> y.eSet(x.eGet(feature)) when x and y share the same features (i.e.,
> features of the common super class). Of course if the feature is a
> containment feature, the values will actually be removed from x and
> added to y, so some careful thinking is in order...
>>
>> This would allow me to build an enhanced version of my existing (and
>> populated) static model at runtime.
> One could imagine a cross model Copier where you feed it an instance of
> the base model and not only does it make a copy of it, but the copies
> are actually instances of a derived (perhaps dynamic) model. The
> getTarget methods of the Copier can be specialized for that purpose.
> You might well be better off making your base model support decorations
> though so that it can be decorated to enhance it rather than needed to
> be extended (much like EModelElement supports EAnnotations for that
> purpose).
>>
>> Thanx! Christophe
|
|
|
| Re: Dynamic EMF , instantiation of Super class [message #479537 is a reply to message #479536] |
Tue, 11 August 2009 13:24 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
Christophe Bouhier wrote:
> Ah yes, I'd like to order one copier like that please. :-)
It's really quite a trivial thing to derive from EcoreUtil.Copier and
override the two getTarget methods...
> Not sure about model decorations, the index of the EMF book, wasn't
> either...
The point is just to ensure that the base model has a mechanism for
attaching other kinds of objects to hold extra data (decorations).
E.g., just as Java, XML Schema, and Ecore all have support for
annotations...
>
> Now I think of it, In a dynamic model, instead of creating boiler
> plate to access the features (Which I just did), could OCL be used on
> the dynamic model? (As OCL , I assume the OCL implementation uses the
> reflection API to get and check stuff).
Yes, OCL will work with reflection and should work with dynamic models.
>
> Christophe
>
>
>
> Ed Merks wrote:
>> Christophe,
>>
>> Comments below.
>>
>>
>> Christophe Bouhier wrote:
>>> related to my previous question, how to enhance my model with a
>>> custom operation, I started to look at Dynamic EMF, which is
>>> actually very cool.
>> Yes, it kind of a cool surprise to learn that you don't need to
>> generate code and yet still have all the benefits of a strongly typed
>> reflective model.
>>>
>>> Now if I create an instance of a dynamicly created class with a
>>> super type set to an existing static ECore class. the features for
>>> the super class are obviously not set.
>> It's generally true (or should be) that when you create a instance of
>> any EClass that none of its features will be set.
>>> But let's say I have an instance of the same type as the super
>>> class, can I somehow copy-in the feature values with i.e. ECoreUtil?
>> Things like EcoreUtil.Copier can be used in pretty interesting
>> ways. Even without it, it's certainly possible to call
>> y.eSet(x.eGet(feature)) when x and y share the same features (i.e.,
>> features of the common super class). Of course if the feature is a
>> containment feature, the values will actually be removed from x and
>> added to y, so some careful thinking is in order...
>>>
>>> This would allow me to build an enhanced version of my existing (and
>>> populated) static model at runtime.
>> One could imagine a cross model Copier where you feed it an instance
>> of the base model and not only does it make a copy of it, but the
>> copies are actually instances of a derived (perhaps dynamic) model.
>> The getTarget methods of the Copier can be specialized for that
>> purpose. You might well be better off making your base model support
>> decorations though so that it can be decorated to enhance it rather
>> than needed to be extended (much like EModelElement supports
>> EAnnotations for that purpose).
>>>
>>> Thanx! Christophe
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:29:06 GMT 2024
Powered by FUDForum. Page generated in 0.03287 seconds |
] 
Search
Help
Register
Login
Home
