Home » Modeling » EMF » CDO : Reflective or Dynamic feature delegation ?
| | |
| Re: CDO : Reflective or Dynamic feature delegation ? [message #1476757 is a reply to message #1476676] |
Mon, 17 November 2014 10:23   |
|
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
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 |
 Felix Dorner
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 |
Ed Merks
Messages: 33140
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.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: CDO : Reflective or Dynamic feature delegation ? [message #1477820 is a reply to message #1477082] |
Tue, 18 November 2014 06:17 |
Ed Merks
Messages: 33140
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:05:49 GMT 2024
Powered by FUDForum. Page generated in 0.03439 seconds |
] 
Search
Help
Register
Login
Home
