Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO : Reflective or Dynamic feature delegation ?
CDO : Reflective or Dynamic feature delegation ? [message #1473764] Fri, 14 November 2014 22:43 Go to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi,

After one day testing my app (multi-models with many eOpposite features) generated as CDO native - dynamic, I have the feeling, the behavior with EMF utility classes is closer to standard EMF generation.

The behaviors of reflective API : eSet, eGet and eIsSet (used in EcoreUtil.equals for instance ) relying on generated getters / setters seems to work better than when generating with featureDelegation set to Reflective.

Does anyone have some feedbacks about both generations Reflective / Dynamic in CDO context ?

St├ęphane.
Re: CDO : Reflective or Dynamic feature delegation ? [message #1476666 is a reply to message #1473764] Mon, 17 November 2014 08:44 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hi,


> The behaviors of reflective API : eSet, eGet and eIsSet (used in
> EcoreUtil.equals for instance ) relying on generated getters / setters
> seems to work better than when generating with featureDelegation set to
> Reflective.

Better? Iirc, it doesn't work at all if you set it to dynamic.

> Does anyone have some feedbacks about both generations Reflective /
> Dynamic in CDO context ?

I wanted the 'cdo team' of our product to switch to reflective
generation for a long time now so that I can close several application
bugs.. Anything that uses EMF reflection breaks when you use dynamic
feature delegation... (Unfortunately I'm not aware of the stuff that
might break when you switch to reflective generation, but I'm willing to
find out if I can close all existing bugs related to eGet/eSet/eIsSet
not working correctly in the cdo edition)

Felix
Re: CDO : Reflective or Dynamic feature delegation ? [message #1476676 is a reply to message #1476666] Mon, 17 November 2014 08:54 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
On 17/11/2014 09:44, Felix Dorner wrote:
> Hi,
>
>
>> The behaviors of reflective API : eSet, eGet and eIsSet (used in
>> EcoreUtil.equals for instance ) relying on generated getters / setters
>> seems to work better than when generating with featureDelegation set to
>> Reflective.
>
> Better? Iirc, it doesn't work at all if you set it to dynamic.
>

Sorry, more precisely, doesn't work at all as in "Your customized code
in getters/setters won't be used", most obviously the case for derived
features.
Re: CDO : Reflective or Dynamic feature delegation ? [message #1476757 is a reply to message #1476676] Mon, 17 November 2014 10:23 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
Am 17.11.2014 um 09:54 schrieb Felix Dorner:
> On 17/11/2014 09:44, Felix Dorner wrote:
>> Hi,
>>
>>
>>> The behaviors of reflective API : eSet, eGet and eIsSet (used in
>>> EcoreUtil.equals for instance ) relying on generated getters / setters
>>> seems to work better than when generating with featureDelegation set to
>>> Reflective.
>>
>> Better? Iirc, it doesn't work at all if you set it to dynamic.
>>
>
> Sorry, more precisely, doesn't work at all as in "Your customized code in getters/setters won't be used", most
> obviously the case for derived features.
I found a comment by Ed that clarifies this:

Reflective calls the generated accessors which call the dynamic
accessors whereas Dynamic the generated accessors call the reflective
accessors which call the dynamic accessors. The former is flexible if
you override the generated accessors, the latter are more efficient when
the reflective API is invoked directly, as is the case for most of the
framework's use of the instances.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: CDO : Reflective or Dynamic feature delegation ? [message #1476937 is a reply to message #1476757] Mon, 17 November 2014 13:33 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
If I use dynamic to benefit from more efficient reflective code, is
there a some other way to 'implement' derived features, so that the
result is computed somewhere in the 'dynamic' part?

Felix

On 17/11/2014 11:23, Eike Stepper wrote:
> Am 17.11.2014 um 09:54 schrieb Felix Dorner:
>> On 17/11/2014 09:44, Felix Dorner wrote:
>>> Hi,
>>>
>>>
>>>> The behaviors of reflective API : eSet, eGet and eIsSet (used in
>>>> EcoreUtil.equals for instance ) relying on generated getters / setters
>>>> seems to work better than when generating with featureDelegation set to
>>>> Reflective.
>>>
>>> Better? Iirc, it doesn't work at all if you set it to dynamic.
>>>
>>
>> Sorry, more precisely, doesn't work at all as in "Your customized code
>> in getters/setters won't be used", most obviously the case for derived
>> features.
> I found a comment by Ed that clarifies this:
>
> Reflective calls the generated accessors which call the dynamic
> accessors whereas Dynamic the generated accessors call the reflective
> accessors which call the dynamic accessors. The former is flexible if
> you override the generated accessors, the latter are more efficient when
> the reflective API is invoked directly, as is the case for most of the
> framework's use of the instances.
Re: CDO : Reflective or Dynamic feature delegation ? [message #1477034 is a reply to message #1476937] Mon, 17 November 2014 15:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30140
Registered: July 2009
Senior Member
Felix,

No doubt when all the levels of indirection involved in a CDO/Store
implementation, the performance difference is irrelevant. Measure it
before you worry about it.

On 17/11/2014 2:33 PM, Felix Dorner wrote:
> If I use dynamic to benefit from more efficient reflective code, is
> there a some other way to 'implement' derived features, so that the
> result is computed somewhere in the 'dynamic' part?
>
> Felix
>
> On 17/11/2014 11:23, Eike Stepper wrote:
>> Am 17.11.2014 um 09:54 schrieb Felix Dorner:
>>> On 17/11/2014 09:44, Felix Dorner wrote:
>>>> Hi,
>>>>
>>>>
>>>>> The behaviors of reflective API : eSet, eGet and eIsSet (used in
>>>>> EcoreUtil.equals for instance ) relying on generated getters /
>>>>> setters
>>>>> seems to work better than when generating with featureDelegation
>>>>> set to
>>>>> Reflective.
>>>>
>>>> Better? Iirc, it doesn't work at all if you set it to dynamic.
>>>>
>>>
>>> Sorry, more precisely, doesn't work at all as in "Your customized code
>>> in getters/setters won't be used", most obviously the case for derived
>>> features.
>> I found a comment by Ed that clarifies this:
>>
>> Reflective calls the generated accessors which call the dynamic
>> accessors whereas Dynamic the generated accessors call the reflective
>> accessors which call the dynamic accessors. The former is flexible if
>> you override the generated accessors, the latter are more efficient when
>> the reflective API is invoked directly, as is the case for most of the
>> framework's use of the instances.
>
Re: CDO : Reflective or Dynamic feature delegation ? [message #1477082 is a reply to message #1477034] Mon, 17 November 2014 15:58 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Ciao,

On 17/11/2014 16:13, Ed Merks wrote:
> Felix,
>
> No doubt when all the levels of indirection involved in a CDO/Store
> implementation, the performance difference is irrelevant. Measure it
> before you worry about it.

Sorry, I asked wrongly. I don't worry nor measure (lucky me!). After
looking at the difference of the two generation patterns I'd be the
first to flip the switch without hesitation. I just wanted to know if
there are alternatives to implement derived features through some other
CDO-specific mechanism.

Felix
Re: CDO : Reflective or Dynamic feature delegation ? [message #1477820 is a reply to message #1477082] Tue, 18 November 2014 06:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30140
Registered: July 2009
Senior Member
Felix,

No, I don't believe CDO provides any other way to compute a derived
feature's value.

On 17/11/2014 4:58 PM, Felix Dorner wrote:
> Ciao,
>
> On 17/11/2014 16:13, Ed Merks wrote:
>> Felix,
>>
>> No doubt when all the levels of indirection involved in a CDO/Store
>> implementation, the performance difference is irrelevant. Measure it
>> before you worry about it.
>
> Sorry, I asked wrongly. I don't worry nor measure (lucky me!). After
> looking at the difference of the two generation patterns I'd be the
> first to flip the switch without hesitation. I just wanted to know if
> there are alternatives to implement derived features through some
> other CDO-specific mechanism.
>
> Felix
>
Previous Topic:[oomph] adding new setup will not add git repositories to view
Next Topic:Rookie Q: How get StyledCellLabelProvider from EMF.edit
Goto Forum:
  


Current Time: Sat May 25 13:16:10 GMT 2019

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

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

Back to the top