Home » Modeling » EMF » Reflective Feature Delegation: Reflective methods don't call the generated get/set methods?
| |
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419146 is a reply to message #419144] |
Fri, 09 May 2008 20:26   |
 Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks for your feedback, please see my reply inline:
Ed Merks schrieb:
> Sandro,
>
> Comments below.
>
> Sandro Böhme wrote:
>> Hello,
>>
>> when generating an ecore model with the "Reflective" flag set for
>> "Feature Delegation" the generated methods for my features are not
>> getting called on the reflective eGet() and eSet() methods.
> Yes, the delegation is in the other direction. I.e., the generated getX
> calls eGet(<X-feature).
>> Thus if I
>> would change the behavior of my features in the generated methods it
>> would not be usable when working with the reflective API. Is this just a
>> bug or is it the way it should work?
> Yes, that's how it should work. An advantage of this approach is that
> it produces very little byte code. It also allows for things like
> delegating onto a store-backed implementation.
>> I tried to change the Class.javajet to generate the eSet() and eGet()
>> methods similar to "Feature Delegation"="None" and the features to
>> call super.eGet and super.eSet but this adds a circular dependency and
>> does not work. If it's a bug there doesn't seem to be an easy fix.
> I guess I'm wondering what you're trying to achieve? There's the normal
I just tried to find a way to keep the CPU busy. Thus the circular
delegation. Life would just be boring for the CPU in my application ;-).
Actually I don't do something special. The breakpoint in the generated
getX() method is just never reached when using the generated editor
plugin and it looked like it never could reach it. Am I supposed to
call the generated getX() / setX() methods in some way in my store? At
the moment I have no idea how that could be done when the reflective
mechanism works the other way around.
> pattern where the reflective methods generate to your generated
> hand-modifiable methods and the reflective pattern that does the exact
> opposite. It seems you need to pick one of the two, and that the third
> choice is circular delegation, which seems not so useful. :-P
>> Thanks in advance for any feedback.
>>
>> Best regards,
>>
>> Sandro
Best,
Sandro
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419148 is a reply to message #419146] |
Fri, 09 May 2008 20:48 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
The idea is to use the reflective delegation while settings the root
extends class to DynamicEObjectImpl or EStoreEObjectImpl. Calling getX
in the API will call eGet(<X-feature>) which will delegate to the store
(or the dynamic object's array of feature value holders) to get the
value. If you call eGet directly, the process is shortcut. So the
generate API is just a facade over the reflective one...
Sandro Böhme wrote:
> Hi Ed,
> thanks for your feedback, please see my reply inline:
>
> Ed Merks schrieb:
>> Sandro,
>>
>> Comments below.
>>
>> Sandro Böhme wrote:
>>> Hello,
>>>
>>> when generating an ecore model with the "Reflective" flag set for
>>> "Feature Delegation" the generated methods for my features are not
>>> getting called on the reflective eGet() and eSet() methods.
>> Yes, the delegation is in the other direction. I.e., the generated
>> getX calls eGet(<X-feature).
>>> Thus if I
>>> would change the behavior of my features in the generated methods it
>>> would not be usable when working with the reflective API. Is this
>>> just a
>>> bug or is it the way it should work?
>> Yes, that's how it should work. An advantage of this approach is
>> that it produces very little byte code. It also allows for things
>> like delegating onto a store-backed implementation.
>>> I tried to change the Class.javajet to generate the eSet() and
>>> eGet() methods similar to "Feature Delegation"="None" and the
>>> features to call super.eGet and super.eSet but this adds a circular
>>> dependency and does not work. If it's a bug there doesn't seem to be
>>> an easy fix.
>> I guess I'm wondering what you're trying to achieve? There's the normal
> I just tried to find a way to keep the CPU busy. Thus the circular
> delegation. Life would just be boring for the CPU in my application ;-).
>
> Actually I don't do something special. The breakpoint in the generated
> getX() method is just never reached when using the generated editor
> plugin and it looked like it never could reach it. Am I supposed to
> call the generated getX() / setX() methods in some way in my store? At
> the moment I have no idea how that could be done when the reflective
> mechanism works the other way around.
>
>> pattern where the reflective methods generate to your generated
>> hand-modifiable methods and the reflective pattern that does the
>> exact opposite. It seems you need to pick one of the two, and that
>> the third choice is circular delegation, which seems not so useful. :-P
>>> Thanks in advance for any feedback.
>>>
>>> Best regards,
>>>
>>> Sandro
>
> Best,
>
> Sandro
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419157 is a reply to message #419148] |
Sat, 10 May 2008 09:21 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
it's clear to me how it works in this direction. My understanding is
just, that it's possible with EMF to work the other way around too. That
the reflective API can call the generated getX()/setX() methods when
setting the feature delegation to "Reflective". But I'm probably simply
wrong with that.
To back EMF with the Java Content Repository I use the EStore API
already to facilitate lazy loading. This is why I set the feature
delegation to reflective and all EClasses inherit from my EStore instead
of EObject. Now I would like to tell my API users that they can use the
generated getX/setX methods directly or they can use the reflective API
of EMF while the logic they implemented in the getX/setX methods will
always be used. Is this a valid use case of EMF?
Bye,
Sandro
Ed Merks schrieb:
> Sandro,
>
> The idea is to use the reflective delegation while settings the root
> extends class to DynamicEObjectImpl or EStoreEObjectImpl. Calling getX
> in the API will call eGet(<X-feature>) which will delegate to the store
> (or the dynamic object's array of feature value holders) to get the
> value. If you call eGet directly, the process is shortcut. So the
> generate API is just a facade over the reflective one...
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>> thanks for your feedback, please see my reply inline:
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> Comments below.
>>>
>>> Sandro Böhme wrote:
>>>> Hello,
>>>>
>>>> when generating an ecore model with the "Reflective" flag set for
>>>> "Feature Delegation" the generated methods for my features are not
>>>> getting called on the reflective eGet() and eSet() methods.
>>> Yes, the delegation is in the other direction. I.e., the generated
>>> getX calls eGet(<X-feature).
>>>> Thus if I
>>>> would change the behavior of my features in the generated methods it
>>>> would not be usable when working with the reflective API. Is this
>>>> just a
>>>> bug or is it the way it should work?
>>> Yes, that's how it should work. An advantage of this approach is
>>> that it produces very little byte code. It also allows for things
>>> like delegating onto a store-backed implementation.
>>>> I tried to change the Class.javajet to generate the eSet() and
>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>> features to call super.eGet and super.eSet but this adds a circular
>>>> dependency and does not work. If it's a bug there doesn't seem to be
>>>> an easy fix.
>>> I guess I'm wondering what you're trying to achieve? There's the normal
>> I just tried to find a way to keep the CPU busy. Thus the circular
>> delegation. Life would just be boring for the CPU in my application ;-).
>>
>> Actually I don't do something special. The breakpoint in the generated
>> getX() method is just never reached when using the generated editor
>> plugin and it looked like it never could reach it. Am I supposed to
>> call the generated getX() / setX() methods in some way in my store? At
>> the moment I have no idea how that could be done when the reflective
>> mechanism works the other way around.
>>
>>> pattern where the reflective methods generate to your generated
>>> hand-modifiable methods and the reflective pattern that does the
>>> exact opposite. It seems you need to pick one of the two, and that
>>> the third choice is circular delegation, which seems not so useful. :-P
>>>> Thanks in advance for any feedback.
>>>>
>>>> Best regards,
>>>>
>>>> Sandro
>>
>> Best,
>>
>> Sandro
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419160 is a reply to message #419157] |
Sat, 10 May 2008 20:50 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
Comments below.
Sandro Böhme wrote:
> Hi Ed,
>
> it's clear to me how it works in this direction. My understanding is
> just, that it's possible with EMF to work the other way around too.
> That the reflective API can call the generated getX()/setX() methods
> when setting the feature delegation to "Reflective". But I'm probably
> simply wrong with that.
No. I'm having trouble imagining what the pattern would look like.
With the normal pattern calling eGet(<X>) would call getX() which
returns the value of a variable, or could be specialized to do something
funky. With reflective delegation calling getX would call eGet(<X>)
which would delegate onto the store. So you user could specialize eGet
itself and handle the <X> feature in some special way. I.e., normally
you generate eGet to call getX and specialize that; with reflective
delegation, getX calles eGet, which isn't generated at all so you'd
specialize that.
>
> To back EMF with the Java Content Repository I use the EStore API
> already to facilitate lazy loading. This is why I set the feature
> delegation to reflective and all EClasses inherit from my EStore
> instead of EObject. Now I would like to tell my API users that they
> can use
But by "use", you do you mean call them (which works file) or specialize
their code (which is not sufficient because EMF reflection will never
call those methods).
> the generated getX/setX methods directly or they can use the
> reflective API of EMF while the logic they implemented in the
> getX/setX methods will always be used. Is this a valid use case of EMF?
I'd certainly not something I've ever explored...
>
> Bye,
>
> Sandro
>
> Ed Merks schrieb:
>> Sandro,
>>
>> The idea is to use the reflective delegation while settings the root
>> extends class to DynamicEObjectImpl or EStoreEObjectImpl. Calling
>> getX in the API will call eGet(<X-feature>) which will delegate to
>> the store (or the dynamic object's array of feature value holders) to
>> get the value. If you call eGet directly, the process is shortcut.
>> So the generate API is just a facade over the reflective one...
>>
>>
>> Sandro Böhme wrote:
>>> Hi Ed,
>>> thanks for your feedback, please see my reply inline:
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> Comments below.
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hello,
>>>>>
>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>> "Feature Delegation" the generated methods for my features are not
>>>>> getting called on the reflective eGet() and eSet() methods.
>>>> Yes, the delegation is in the other direction. I.e., the generated
>>>> getX calls eGet(<X-feature).
>>>>> Thus if I
>>>>> would change the behavior of my features in the generated methods it
>>>>> would not be usable when working with the reflective API. Is this
>>>>> just a
>>>>> bug or is it the way it should work?
>>>> Yes, that's how it should work. An advantage of this approach is
>>>> that it produces very little byte code. It also allows for things
>>>> like delegating onto a store-backed implementation.
>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>> features to call super.eGet and super.eSet but this adds a
>>>>> circular dependency and does not work. If it's a bug there doesn't
>>>>> seem to be an easy fix.
>>>> I guess I'm wondering what you're trying to achieve? There's the
>>>> normal
>>> I just tried to find a way to keep the CPU busy. Thus the circular
>>> delegation. Life would just be boring for the CPU in my application
>>> ;-).
>>>
>>> Actually I don't do something special. The breakpoint in the
>>> generated getX() method is just never reached when using the
>>> generated editor plugin and it looked like it never could reach it.
>>> Am I supposed to
>>> call the generated getX() / setX() methods in some way in my store?
>>> At the moment I have no idea how that could be done when the
>>> reflective mechanism works the other way around.
>>>
>>>> pattern where the reflective methods generate to your generated
>>>> hand-modifiable methods and the reflective pattern that does the
>>>> exact opposite. It seems you need to pick one of the two, and
>>>> that the third choice is circular delegation, which seems not so
>>>> useful. :-P
>>>>> Thanks in advance for any feedback.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Sandro
>>>
>>> Best,
>>>
>>> Sandro
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419163 is a reply to message #419160] |
Sat, 10 May 2008 23:14 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
please see my comments inline.
Ed Merks schrieb:
> Sandro,
>
> Comments below.
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> it's clear to me how it works in this direction. My understanding is
>> just, that it's possible with EMF to work the other way around too.
>> That the reflective API can call the generated getX()/setX() methods
>> when setting the feature delegation to "Reflective". But I'm probably
>> simply wrong with that.
> No. I'm having trouble imagining what the pattern would look like.
> With the normal pattern calling eGet(<X>) would call getX() which
> returns the value of a variable, or could be specialized to do something
> funky. With reflective delegation calling getX would call eGet(<X>)
> which would delegate onto the store. So you user could specialize eGet
> itself and handle the <X> feature in some special way. I.e., normally
> you generate eGet to call getX and specialize that; with reflective
> delegation, getX calles eGet, which isn't generated at all so you'd
> specialize that.
that would certainly work. But I afraid I would have a hard time
explaining them why they should not specialize the generated feature
methods (getX/setX) but instead create and specialize the reflective
eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
methods. I will investigate deeper and try to find a way to let the user
specialize the getX()/setX() methods.
>>
>> To back EMF with the Java Content Repository I use the EStore API
>> already to facilitate lazy loading. This is why I set the feature
>> delegation to reflective and all EClasses inherit from my EStore
>> instead of EObject. Now I would like to tell my API users that they
>> can use
> But by "use", you do you mean call them (which works file) or specialize
> their code (which is not sufficient because EMF reflection will never
> call those methods).
I mean specialize the code.
Bye,
Sandro
>> the generated getX/setX methods directly or they can use the
>> reflective API of EMF while the logic they implemented in the
>> getX/setX methods will always be used. Is this a valid use case of EMF?
> I'd certainly not something I've ever explored...
>>
>> Bye,
>>
>> Sandro
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> The idea is to use the reflective delegation while settings the root
>>> extends class to DynamicEObjectImpl or EStoreEObjectImpl. Calling
>>> getX in the API will call eGet(<X-feature>) which will delegate to
>>> the store (or the dynamic object's array of feature value holders) to
>>> get the value. If you call eGet directly, the process is shortcut.
>>> So the generate API is just a facade over the reflective one...
>>>
>>>
>>> Sandro Böhme wrote:
>>>> Hi Ed,
>>>> thanks for your feedback, please see my reply inline:
>>>>
>>>> Ed Merks schrieb:
>>>>> Sandro,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Sandro Böhme wrote:
>>>>>> Hello,
>>>>>>
>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>> Yes, the delegation is in the other direction. I.e., the generated
>>>>> getX calls eGet(<X-feature).
>>>>>> Thus if I
>>>>>> would change the behavior of my features in the generated methods it
>>>>>> would not be usable when working with the reflective API. Is this
>>>>>> just a
>>>>>> bug or is it the way it should work?
>>>>> Yes, that's how it should work. An advantage of this approach is
>>>>> that it produces very little byte code. It also allows for things
>>>>> like delegating onto a store-backed implementation.
>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>> circular dependency and does not work. If it's a bug there doesn't
>>>>>> seem to be an easy fix.
>>>>> I guess I'm wondering what you're trying to achieve? There's the
>>>>> normal
>>>> I just tried to find a way to keep the CPU busy. Thus the circular
>>>> delegation. Life would just be boring for the CPU in my application
>>>> ;-).
>>>>
>>>> Actually I don't do something special. The breakpoint in the
>>>> generated getX() method is just never reached when using the
>>>> generated editor plugin and it looked like it never could reach it.
>>>> Am I supposed to
>>>> call the generated getX() / setX() methods in some way in my store?
>>>> At the moment I have no idea how that could be done when the
>>>> reflective mechanism works the other way around.
>>>>
>>>>> pattern where the reflective methods generate to your generated
>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>> that the third choice is circular delegation, which seems not so
>>>>> useful. :-P
>>>>>> Thanks in advance for any feedback.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Sandro
>>>>
>>>> Best,
>>>>
>>>> Sandro
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419166 is a reply to message #419163] |
Sun, 11 May 2008 00:25 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
I could imagine using a non-reflective pattern and then generating a
getX that directly calls dynamicGet(X-index), and so on for the other
accessors...
Sandro Böhme wrote:
> Hi Ed,
>
> please see my comments inline.
>
> Ed Merks schrieb:
>> Sandro,
>>
>> Comments below.
>>
>>
>> Sandro Böhme wrote:
>>> Hi Ed,
>>>
>>> it's clear to me how it works in this direction. My understanding is
>>> just, that it's possible with EMF to work the other way around too.
>>> That the reflective API can call the generated getX()/setX() methods
>>> when setting the feature delegation to "Reflective". But I'm
>>> probably simply wrong with that.
>> No. I'm having trouble imagining what the pattern would look like.
>> With the normal pattern calling eGet(<X>) would call getX() which
>> returns the value of a variable, or could be specialized to do
>> something funky. With reflective delegation calling getX would call
>> eGet(<X>) which would delegate onto the store. So you user could
>> specialize eGet itself and handle the <X> feature in some special
>> way. I.e., normally you generate eGet to call getX and specialize
>> that; with reflective delegation, getX calles eGet, which isn't
>> generated at all so you'd specialize that.
> that would certainly work. But I afraid I would have a hard time
> explaining them why they should not specialize the generated feature
> methods (getX/setX) but instead create and specialize the reflective
> eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
> methods. I will investigate deeper and try to find a way to let the
> user specialize the getX()/setX() methods.
>
>>>
>>> To back EMF with the Java Content Repository I use the EStore API
>>> already to facilitate lazy loading. This is why I set the feature
>>> delegation to reflective and all EClasses inherit from my EStore
>>> instead of EObject. Now I would like to tell my API users that they
>>> can use
>> But by "use", you do you mean call them (which works file) or
>> specialize their code (which is not sufficient because EMF reflection
>> will never call those methods).
> I mean specialize the code.
>
> Bye,
>
> Sandro
>
>>> the generated getX/setX methods directly or they can use the
>>> reflective API of EMF while the logic they implemented in the
>>> getX/setX methods will always be used. Is this a valid use case of EMF?
>> I'd certainly not something I've ever explored...
>>>
>>> Bye,
>>>
>>> Sandro
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> The idea is to use the reflective delegation while settings the
>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>> delegate to the store (or the dynamic object's array of feature
>>>> value holders) to get the value. If you call eGet directly, the
>>>> process is shortcut. So the generate API is just a facade over the
>>>> reflective one...
>>>>
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hi Ed,
>>>>> thanks for your feedback, please see my reply inline:
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Sandro,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Sandro Böhme wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>> generated getX calls eGet(<X-feature).
>>>>>>> Thus if I
>>>>>>> would change the behavior of my features in the generated
>>>>>>> methods it
>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>> this just a
>>>>>>> bug or is it the way it should work?
>>>>>> Yes, that's how it should work. An advantage of this approach is
>>>>>> that it produces very little byte code. It also allows for
>>>>>> things like delegating onto a store-backed implementation.
>>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>>> circular dependency and does not work. If it's a bug there
>>>>>>> doesn't seem to be an easy fix.
>>>>>> I guess I'm wondering what you're trying to achieve? There's the
>>>>>> normal
>>>>> I just tried to find a way to keep the CPU busy. Thus the circular
>>>>> delegation. Life would just be boring for the CPU in my
>>>>> application ;-).
>>>>>
>>>>> Actually I don't do something special. The breakpoint in the
>>>>> generated getX() method is just never reached when using the
>>>>> generated editor plugin and it looked like it never could reach
>>>>> it. Am I supposed to
>>>>> call the generated getX() / setX() methods in some way in my
>>>>> store? At the moment I have no idea how that could be done when
>>>>> the reflective mechanism works the other way around.
>>>>>
>>>>>> pattern where the reflective methods generate to your generated
>>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>>> that the third choice is circular delegation, which seems not so
>>>>>> useful. :-P
>>>>>>> Thanks in advance for any feedback.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Sandro
>>>>>
>>>>> Best,
>>>>>
>>>>> Sandro
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419168 is a reply to message #419163] |
Sun, 11 May 2008 15:41 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------040506010505030605020609
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Hi Ed,
after stumbling over a solution that only speeded up the circular
delegation I can come up with a solution that at least works for me. I'm
not sure if it's also applicable for others and what other implications
it has. I changed the Class.javajet to generate the following for
Feature Delegation="Reflective":
public void setTitle(String newTitle) {
super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
}
public String getTitle() {
return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true, true);
}
The eGet() and eSet() methods are generated equal to Feature
Delegation="None".
Attached you find the patch for Class.javajet to see what I changed there.
The result is that getX()/setX() calls the generated reflective methods
of all super classes until it ends up in
BasicEObjectImpl.eGet(featureID, resolve, coreType) and
BasicEObjectImpl.eSet(featureID, newValue)
++ Downside ++
One downside is, that it's wasted time to walk up the whole inheritance
hierachy as the right feature is already called and it's not needed to
search for it while walking up the hierarchy.
The method
BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
boolean coreType) is skipped which basically means that
BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called for
getX()/setX() methods. This will probably raise problems too. But I
don't know what the use case for this method is.
++ Upside ++
The upside is, that one can say that a specialized model with feature
delegation set to "Reflective" behaves equal no matter if it's accessed
directly with the getX()/setX() methods or if it's accessed reflectively
with the eGet(<X>)/eSet(<X>) methods. My understanding of EMF is, that
this is an important goal.
What do you think?
Ciao,
Sandro
Sandro B
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419171 is a reply to message #419166] |
Sun, 11 May 2008 15:46 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
this sounds like a straight and performant solution. I guess this would
need an other kind of feature delegation like Feature Delegation =
"EStore" or something like that. I'm not afraid of getting my hands
dirty but you see that as an EMF use cases and not as a use case of JCRM
or other downstream users right?
Ciao,
Sandro
Ed Merks schrieb:
> Sandro,
>
> I could imagine using a non-reflective pattern and then generating a
> getX that directly calls dynamicGet(X-index), and so on for the other
> accessors...
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> please see my comments inline.
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> Comments below.
>>>
>>>
>>> Sandro Böhme wrote:
>>>> Hi Ed,
>>>>
>>>> it's clear to me how it works in this direction. My understanding is
>>>> just, that it's possible with EMF to work the other way around too.
>>>> That the reflective API can call the generated getX()/setX() methods
>>>> when setting the feature delegation to "Reflective". But I'm
>>>> probably simply wrong with that.
>>> No. I'm having trouble imagining what the pattern would look like.
>>> With the normal pattern calling eGet(<X>) would call getX() which
>>> returns the value of a variable, or could be specialized to do
>>> something funky. With reflective delegation calling getX would call
>>> eGet(<X>) which would delegate onto the store. So you user could
>>> specialize eGet itself and handle the <X> feature in some special
>>> way. I.e., normally you generate eGet to call getX and specialize
>>> that; with reflective delegation, getX calles eGet, which isn't
>>> generated at all so you'd specialize that.
>> that would certainly work. But I afraid I would have a hard time
>> explaining them why they should not specialize the generated feature
>> methods (getX/setX) but instead create and specialize the reflective
>> eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
>> methods. I will investigate deeper and try to find a way to let the
>> user specialize the getX()/setX() methods.
>>
>>>>
>>>> To back EMF with the Java Content Repository I use the EStore API
>>>> already to facilitate lazy loading. This is why I set the feature
>>>> delegation to reflective and all EClasses inherit from my EStore
>>>> instead of EObject. Now I would like to tell my API users that they
>>>> can use
>>> But by "use", you do you mean call them (which works file) or
>>> specialize their code (which is not sufficient because EMF reflection
>>> will never call those methods).
>> I mean specialize the code.
>>
>> Bye,
>>
>> Sandro
>>
>>>> the generated getX/setX methods directly or they can use the
>>>> reflective API of EMF while the logic they implemented in the
>>>> getX/setX methods will always be used. Is this a valid use case of EMF?
>>> I'd certainly not something I've ever explored...
>>>>
>>>> Bye,
>>>>
>>>> Sandro
>>>>
>>>> Ed Merks schrieb:
>>>>> Sandro,
>>>>>
>>>>> The idea is to use the reflective delegation while settings the
>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>> delegate to the store (or the dynamic object's array of feature
>>>>> value holders) to get the value. If you call eGet directly, the
>>>>> process is shortcut. So the generate API is just a facade over the
>>>>> reflective one...
>>>>>
>>>>>
>>>>> Sandro Böhme wrote:
>>>>>> Hi Ed,
>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Sandro,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Sandro Böhme wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>> Thus if I
>>>>>>>> would change the behavior of my features in the generated
>>>>>>>> methods it
>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>> this just a
>>>>>>>> bug or is it the way it should work?
>>>>>>> Yes, that's how it should work. An advantage of this approach is
>>>>>>> that it produces very little byte code. It also allows for
>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>>>> circular dependency and does not work. If it's a bug there
>>>>>>>> doesn't seem to be an easy fix.
>>>>>>> I guess I'm wondering what you're trying to achieve? There's the
>>>>>>> normal
>>>>>> I just tried to find a way to keep the CPU busy. Thus the circular
>>>>>> delegation. Life would just be boring for the CPU in my
>>>>>> application ;-).
>>>>>>
>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>> generated getX() method is just never reached when using the
>>>>>> generated editor plugin and it looked like it never could reach
>>>>>> it. Am I supposed to
>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>> store? At the moment I have no idea how that could be done when
>>>>>> the reflective mechanism works the other way around.
>>>>>>
>>>>>>> pattern where the reflective methods generate to your generated
>>>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>>>> that the third choice is circular delegation, which seems not so
>>>>>>> useful. :-P
>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Sandro
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Sandro
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419172 is a reply to message #419168] |
Sun, 11 May 2008 17:14 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
I still need to look very closely, and it's weekend, but I wonder if
calling eDynamicGet(int, EStructuralFeature, boolean, boolean) wouldn't
be equivalent but better performing.
Sandro Böhme wrote:
> Hi Ed,
>
> after stumbling over a solution that only speeded up the circular
> delegation I can come up with a solution that at least works for me.
> I'm not sure if it's also applicable for others and what other
> implications it has. I changed the Class.javajet to generate the
> following for Feature Delegation="Reflective":
>
> public void setTitle(String newTitle) {
> super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
> }
>
>
> public String getTitle() {
> return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true, true);
> }
> The eGet() and eSet() methods are generated equal to Feature
> Delegation="None".
>
> Attached you find the patch for Class.javajet to see what I changed
> there.
>
> The result is that getX()/setX() calls the generated reflective
> methods of all super classes until it ends up in
> BasicEObjectImpl.eGet(featureID, resolve, coreType) and
> BasicEObjectImpl.eSet(featureID, newValue)
>
> ++ Downside ++
> One downside is, that it's wasted time to walk up the whole
> inheritance hierachy as the right feature is already called and it's
> not needed to search for it while walking up the hierarchy.
> The method
> BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
> boolean coreType) is skipped which basically means that
> BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called
> for getX()/setX() methods. This will probably raise problems too. But
> I don't know what the use case for this method is.
>
> ++ Upside ++
> The upside is, that one can say that a specialized model with feature
> delegation set to "Reflective" behaves equal no matter if it's
> accessed directly with the getX()/setX() methods or if it's accessed
> reflectively with the eGet(<X>)/eSet(<X>) methods. My understanding of
> EMF is, that this is an important goal.
>
> What do you think?
>
> Ciao,
>
> Sandro
>
>
> Sandro Böhme schrieb:
>> Hi Ed,
>>
>> please see my comments inline.
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> Comments below.
>>>
>>>
>>> Sandro Böhme wrote:
>>>> Hi Ed,
>>>>
>>>> it's clear to me how it works in this direction. My understanding
>>>> is just, that it's possible with EMF to work the other way around
>>>> too. That the reflective API can call the generated getX()/setX()
>>>> methods when setting the feature delegation to "Reflective". But
>>>> I'm probably simply wrong with that.
>>> No. I'm having trouble imagining what the pattern would look like.
>>> With the normal pattern calling eGet(<X>) would call getX() which
>>> returns the value of a variable, or could be specialized to do
>>> something funky. With reflective delegation calling getX would call
>>> eGet(<X>) which would delegate onto the store. So you user could
>>> specialize eGet itself and handle the <X> feature in some special
>>> way. I.e., normally you generate eGet to call getX and specialize
>>> that; with reflective delegation, getX calles eGet, which isn't
>>> generated at all so you'd specialize that.
>> that would certainly work. But I afraid I would have a hard time
>> explaining them why they should not specialize the generated feature
>> methods (getX/setX) but instead create and specialize the reflective
>> eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
>> methods. I will investigate deeper and try to find a way to let the
>> user specialize the getX()/setX() methods.
>>
>>>>
>>>> To back EMF with the Java Content Repository I use the EStore API
>>>> already to facilitate lazy loading. This is why I set the feature
>>>> delegation to reflective and all EClasses inherit from my EStore
>>>> instead of EObject. Now I would like to tell my API users that they
>>>> can use
>>> But by "use", you do you mean call them (which works file) or
>>> specialize their code (which is not sufficient because EMF
>>> reflection will never call those methods).
>> I mean specialize the code.
>>
>> Bye,
>>
>> Sandro
>>
>>>> the generated getX/setX methods directly or they can use the
>>>> reflective API of EMF while the logic they implemented in the
>>>> getX/setX methods will always be used. Is this a valid use case of
>>>> EMF?
>>> I'd certainly not something I've ever explored...
>>>>
>>>> Bye,
>>>>
>>>> Sandro
>>>>
>>>> Ed Merks schrieb:
>>>>> Sandro,
>>>>>
>>>>> The idea is to use the reflective delegation while settings the
>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>> delegate to the store (or the dynamic object's array of feature
>>>>> value holders) to get the value. If you call eGet directly, the
>>>>> process is shortcut. So the generate API is just a facade over
>>>>> the reflective one...
>>>>>
>>>>>
>>>>> Sandro Böhme wrote:
>>>>>> Hi Ed,
>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Sandro,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Sandro Böhme wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>> Thus if I
>>>>>>>> would change the behavior of my features in the generated
>>>>>>>> methods it
>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>> this just a
>>>>>>>> bug or is it the way it should work?
>>>>>>> Yes, that's how it should work. An advantage of this approach
>>>>>>> is that it produces very little byte code. It also allows for
>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>>>> circular dependency and does not work. If it's a bug there
>>>>>>>> doesn't seem to be an easy fix.
>>>>>>> I guess I'm wondering what you're trying to achieve? There's
>>>>>>> the normal
>>>>>> I just tried to find a way to keep the CPU busy. Thus the
>>>>>> circular delegation. Life would just be boring for the CPU in my
>>>>>> application ;-).
>>>>>>
>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>> generated getX() method is just never reached when using the
>>>>>> generated editor plugin and it looked like it never could reach
>>>>>> it. Am I supposed to
>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>> store? At the moment I have no idea how that could be done when
>>>>>> the reflective mechanism works the other way around.
>>>>>>
>>>>>>> pattern where the reflective methods generate to your generated
>>>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>>>> that the third choice is circular delegation, which seems not so
>>>>>>> useful. :-P
>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Sandro
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Sandro
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419176 is a reply to message #419172] |
Sun, 11 May 2008 18:37 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Ed Merks schrieb:
> Sandro,
>
> I still need to look very closely, and it's weekend, but I wonder if
> calling eDynamicGet(int, EStructuralFeature, boolean, boolean) wouldn't
> be equivalent but better performing.
Hi Ed,
don't worry. I'm certainly nobody who expects somebody working at weekends.
If eDynamicGet() could be used directly that would be great.
Ciao,
Sandro
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> after stumbling over a solution that only speeded up the circular
>> delegation I can come up with a solution that at least works for me.
>> I'm not sure if it's also applicable for others and what other
>> implications it has. I changed the Class.javajet to generate the
>> following for Feature Delegation="Reflective":
>>
>> public void setTitle(String newTitle) {
>> super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
>> }
>>
>>
>> public String getTitle() {
>> return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true, true);
>> }
>> The eGet() and eSet() methods are generated equal to Feature
>> Delegation="None".
>>
>> Attached you find the patch for Class.javajet to see what I changed
>> there.
>>
>> The result is that getX()/setX() calls the generated reflective
>> methods of all super classes until it ends up in
>> BasicEObjectImpl.eGet(featureID, resolve, coreType) and
>> BasicEObjectImpl.eSet(featureID, newValue)
>>
>> ++ Downside ++
>> One downside is, that it's wasted time to walk up the whole
>> inheritance hierachy as the right feature is already called and it's
>> not needed to search for it while walking up the hierarchy.
>> The method
>> BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
>> boolean coreType) is skipped which basically means that
>> BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called
>> for getX()/setX() methods. This will probably raise problems too. But
>> I don't know what the use case for this method is.
>>
>> ++ Upside ++
>> The upside is, that one can say that a specialized model with feature
>> delegation set to "Reflective" behaves equal no matter if it's
>> accessed directly with the getX()/setX() methods or if it's accessed
>> reflectively with the eGet(<X>)/eSet(<X>) methods. My understanding of
>> EMF is, that this is an important goal.
>>
>> What do you think?
>>
>> Ciao,
>>
>> Sandro
>>
>>
>> Sandro Böhme schrieb:
>>> Hi Ed,
>>>
>>> please see my comments inline.
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hi Ed,
>>>>>
>>>>> it's clear to me how it works in this direction. My understanding
>>>>> is just, that it's possible with EMF to work the other way around
>>>>> too. That the reflective API can call the generated getX()/setX()
>>>>> methods when setting the feature delegation to "Reflective". But
>>>>> I'm probably simply wrong with that.
>>>> No. I'm having trouble imagining what the pattern would look like.
>>>> With the normal pattern calling eGet(<X>) would call getX() which
>>>> returns the value of a variable, or could be specialized to do
>>>> something funky. With reflective delegation calling getX would call
>>>> eGet(<X>) which would delegate onto the store. So you user could
>>>> specialize eGet itself and handle the <X> feature in some special
>>>> way. I.e., normally you generate eGet to call getX and specialize
>>>> that; with reflective delegation, getX calles eGet, which isn't
>>>> generated at all so you'd specialize that.
>>> that would certainly work. But I afraid I would have a hard time
>>> explaining them why they should not specialize the generated feature
>>> methods (getX/setX) but instead create and specialize the reflective
>>> eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
>>> methods. I will investigate deeper and try to find a way to let the
>>> user specialize the getX()/setX() methods.
>>>
>>>>>
>>>>> To back EMF with the Java Content Repository I use the EStore API
>>>>> already to facilitate lazy loading. This is why I set the feature
>>>>> delegation to reflective and all EClasses inherit from my EStore
>>>>> instead of EObject. Now I would like to tell my API users that they
>>>>> can use
>>>> But by "use", you do you mean call them (which works file) or
>>>> specialize their code (which is not sufficient because EMF
>>>> reflection will never call those methods).
>>> I mean specialize the code.
>>>
>>> Bye,
>>>
>>> Sandro
>>>
>>>>> the generated getX/setX methods directly or they can use the
>>>>> reflective API of EMF while the logic they implemented in the
>>>>> getX/setX methods will always be used. Is this a valid use case of
>>>>> EMF?
>>>> I'd certainly not something I've ever explored...
>>>>>
>>>>> Bye,
>>>>>
>>>>> Sandro
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Sandro,
>>>>>>
>>>>>> The idea is to use the reflective delegation while settings the
>>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>>> delegate to the store (or the dynamic object's array of feature
>>>>>> value holders) to get the value. If you call eGet directly, the
>>>>>> process is shortcut. So the generate API is just a facade over
>>>>>> the reflective one...
>>>>>>
>>>>>>
>>>>>> Sandro Böhme wrote:
>>>>>>> Hi Ed,
>>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>>
>>>>>>> Ed Merks schrieb:
>>>>>>>> Sandro,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Sandro Böhme wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>>> Thus if I
>>>>>>>>> would change the behavior of my features in the generated
>>>>>>>>> methods it
>>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>>> this just a
>>>>>>>>> bug or is it the way it should work?
>>>>>>>> Yes, that's how it should work. An advantage of this approach
>>>>>>>> is that it produces very little byte code. It also allows for
>>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>>>>> circular dependency and does not work. If it's a bug there
>>>>>>>>> doesn't seem to be an easy fix.
>>>>>>>> I guess I'm wondering what you're trying to achieve? There's
>>>>>>>> the normal
>>>>>>> I just tried to find a way to keep the CPU busy. Thus the
>>>>>>> circular delegation. Life would just be boring for the CPU in my
>>>>>>> application ;-).
>>>>>>>
>>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>>> generated getX() method is just never reached when using the
>>>>>>> generated editor plugin and it looked like it never could reach
>>>>>>> it. Am I supposed to
>>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>>> store? At the moment I have no idea how that could be done when
>>>>>>> the reflective mechanism works the other way around.
>>>>>>>
>>>>>>>> pattern where the reflective methods generate to your generated
>>>>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>>>>> that the third choice is circular delegation, which seems not so
>>>>>>>> useful. :-P
>>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Sandro
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Sandro
>>
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419253 is a reply to message #419172] |
Wed, 14 May 2008 20:18 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
if you want, I can open a bug for that.
Bye,
Sandro
Ed Merks schrieb:
> Sandro,
>
> I still need to look very closely, and it's weekend, but I wonder if
> calling eDynamicGet(int, EStructuralFeature, boolean, boolean) wouldn't
> be equivalent but better performing.
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> after stumbling over a solution that only speeded up the circular
>> delegation I can come up with a solution that at least works for me.
>> I'm not sure if it's also applicable for others and what other
>> implications it has. I changed the Class.javajet to generate the
>> following for Feature Delegation="Reflective":
>>
>> public void setTitle(String newTitle) {
>> super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
>> }
>>
>>
>> public String getTitle() {
>> return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true, true);
>> }
>> The eGet() and eSet() methods are generated equal to Feature
>> Delegation="None".
>>
>> Attached you find the patch for Class.javajet to see what I changed
>> there.
>>
>> The result is that getX()/setX() calls the generated reflective
>> methods of all super classes until it ends up in
>> BasicEObjectImpl.eGet(featureID, resolve, coreType) and
>> BasicEObjectImpl.eSet(featureID, newValue)
>>
>> ++ Downside ++
>> One downside is, that it's wasted time to walk up the whole
>> inheritance hierachy as the right feature is already called and it's
>> not needed to search for it while walking up the hierarchy.
>> The method
>> BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
>> boolean coreType) is skipped which basically means that
>> BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called
>> for getX()/setX() methods. This will probably raise problems too. But
>> I don't know what the use case for this method is.
>>
>> ++ Upside ++
>> The upside is, that one can say that a specialized model with feature
>> delegation set to "Reflective" behaves equal no matter if it's
>> accessed directly with the getX()/setX() methods or if it's accessed
>> reflectively with the eGet(<X>)/eSet(<X>) methods. My understanding of
>> EMF is, that this is an important goal.
>>
>> What do you think?
>>
>> Ciao,
>>
>> Sandro
>>
>>
>> Sandro Böhme schrieb:
>>> Hi Ed,
>>>
>>> please see my comments inline.
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hi Ed,
>>>>>
>>>>> it's clear to me how it works in this direction. My understanding
>>>>> is just, that it's possible with EMF to work the other way around
>>>>> too. That the reflective API can call the generated getX()/setX()
>>>>> methods when setting the feature delegation to "Reflective". But
>>>>> I'm probably simply wrong with that.
>>>> No. I'm having trouble imagining what the pattern would look like.
>>>> With the normal pattern calling eGet(<X>) would call getX() which
>>>> returns the value of a variable, or could be specialized to do
>>>> something funky. With reflective delegation calling getX would call
>>>> eGet(<X>) which would delegate onto the store. So you user could
>>>> specialize eGet itself and handle the <X> feature in some special
>>>> way. I.e., normally you generate eGet to call getX and specialize
>>>> that; with reflective delegation, getX calles eGet, which isn't
>>>> generated at all so you'd specialize that.
>>> that would certainly work. But I afraid I would have a hard time
>>> explaining them why they should not specialize the generated feature
>>> methods (getX/setX) but instead create and specialize the reflective
>>> eGet(<X>)/eSet(<X>) methods that delegate to their getX()/setX()
>>> methods. I will investigate deeper and try to find a way to let the
>>> user specialize the getX()/setX() methods.
>>>
>>>>>
>>>>> To back EMF with the Java Content Repository I use the EStore API
>>>>> already to facilitate lazy loading. This is why I set the feature
>>>>> delegation to reflective and all EClasses inherit from my EStore
>>>>> instead of EObject. Now I would like to tell my API users that they
>>>>> can use
>>>> But by "use", you do you mean call them (which works file) or
>>>> specialize their code (which is not sufficient because EMF
>>>> reflection will never call those methods).
>>> I mean specialize the code.
>>>
>>> Bye,
>>>
>>> Sandro
>>>
>>>>> the generated getX/setX methods directly or they can use the
>>>>> reflective API of EMF while the logic they implemented in the
>>>>> getX/setX methods will always be used. Is this a valid use case of
>>>>> EMF?
>>>> I'd certainly not something I've ever explored...
>>>>>
>>>>> Bye,
>>>>>
>>>>> Sandro
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Sandro,
>>>>>>
>>>>>> The idea is to use the reflective delegation while settings the
>>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>>> delegate to the store (or the dynamic object's array of feature
>>>>>> value holders) to get the value. If you call eGet directly, the
>>>>>> process is shortcut. So the generate API is just a facade over
>>>>>> the reflective one...
>>>>>>
>>>>>>
>>>>>> Sandro Böhme wrote:
>>>>>>> Hi Ed,
>>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>>
>>>>>>> Ed Merks schrieb:
>>>>>>>> Sandro,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Sandro Böhme wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> when generating an ecore model with the "Reflective" flag set for
>>>>>>>>> "Feature Delegation" the generated methods for my features are not
>>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>>> Thus if I
>>>>>>>>> would change the behavior of my features in the generated
>>>>>>>>> methods it
>>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>>> this just a
>>>>>>>>> bug or is it the way it should work?
>>>>>>>> Yes, that's how it should work. An advantage of this approach
>>>>>>>> is that it produces very little byte code. It also allows for
>>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>>> I tried to change the Class.javajet to generate the eSet() and
>>>>>>>>> eGet() methods similar to "Feature Delegation"="None" and the
>>>>>>>>> features to call super.eGet and super.eSet but this adds a
>>>>>>>>> circular dependency and does not work. If it's a bug there
>>>>>>>>> doesn't seem to be an easy fix.
>>>>>>>> I guess I'm wondering what you're trying to achieve? There's
>>>>>>>> the normal
>>>>>>> I just tried to find a way to keep the CPU busy. Thus the
>>>>>>> circular delegation. Life would just be boring for the CPU in my
>>>>>>> application ;-).
>>>>>>>
>>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>>> generated getX() method is just never reached when using the
>>>>>>> generated editor plugin and it looked like it never could reach
>>>>>>> it. Am I supposed to
>>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>>> store? At the moment I have no idea how that could be done when
>>>>>>> the reflective mechanism works the other way around.
>>>>>>>
>>>>>>>> pattern where the reflective methods generate to your generated
>>>>>>>> hand-modifiable methods and the reflective pattern that does the
>>>>>>>> exact opposite. It seems you need to pick one of the two, and
>>>>>>>> that the third choice is circular delegation, which seems not so
>>>>>>>> useful. :-P
>>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Sandro
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Sandro
>>
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419254 is a reply to message #419253] |
Wed, 14 May 2008 22:16 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
Yes, a bugzilla enhancement request is a good idea because otherwise I'm
unlikely to remember the issue needs attention.
Sandro Böhme wrote:
> Hi Ed,
>
> if you want, I can open a bug for that.
>
> Bye,
> Sandro
>
> Ed Merks schrieb:
>> Sandro,
>>
>> I still need to look very closely, and it's weekend, but I wonder if
>> calling eDynamicGet(int, EStructuralFeature, boolean, boolean)
>> wouldn't be equivalent but better performing.
>>
>>
>> Sandro Böhme wrote:
>>> Hi Ed,
>>>
>>> after stumbling over a solution that only speeded up the circular
>>> delegation I can come up with a solution that at least works for me.
>>> I'm not sure if it's also applicable for others and what other
>>> implications it has. I changed the Class.javajet to generate the
>>> following for Feature Delegation="Reflective":
>>>
>>> public void setTitle(String newTitle) {
>>> super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
>>> }
>>>
>>>
>>> public String getTitle() {
>>> return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true,
>>> true);
>>> }
>>> The eGet() and eSet() methods are generated equal to Feature
>>> Delegation="None".
>>>
>>> Attached you find the patch for Class.javajet to see what I changed
>>> there.
>>>
>>> The result is that getX()/setX() calls the generated reflective
>>> methods of all super classes until it ends up in
>>> BasicEObjectImpl.eGet(featureID, resolve, coreType) and
>>> BasicEObjectImpl.eSet(featureID, newValue)
>>>
>>> ++ Downside ++
>>> One downside is, that it's wasted time to walk up the whole
>>> inheritance hierachy as the right feature is already called and it's
>>> not needed to search for it while walking up the hierarchy.
>>> The method
>>> BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
>>> boolean coreType) is skipped which basically means that
>>> BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called
>>> for getX()/setX() methods. This will probably raise problems too.
>>> But I don't know what the use case for this method is.
>>>
>>> ++ Upside ++
>>> The upside is, that one can say that a specialized model with
>>> feature delegation set to "Reflective" behaves equal no matter if
>>> it's accessed directly with the getX()/setX() methods or if it's
>>> accessed reflectively with the eGet(<X>)/eSet(<X>) methods. My
>>> understanding of EMF is, that this is an important goal.
>>>
>>> What do you think?
>>>
>>> Ciao,
>>>
>>> Sandro
>>>
>>>
>>> Sandro Böhme schrieb:
>>>> Hi Ed,
>>>>
>>>> please see my comments inline.
>>>>
>>>> Ed Merks schrieb:
>>>>> Sandro,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Sandro Böhme wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> it's clear to me how it works in this direction. My understanding
>>>>>> is just, that it's possible with EMF to work the other way around
>>>>>> too. That the reflective API can call the generated getX()/setX()
>>>>>> methods when setting the feature delegation to "Reflective". But
>>>>>> I'm probably simply wrong with that.
>>>>> No. I'm having trouble imagining what the pattern would look
>>>>> like. With the normal pattern calling eGet(<X>) would call getX()
>>>>> which returns the value of a variable, or could be specialized to
>>>>> do something funky. With reflective delegation calling getX would
>>>>> call eGet(<X>) which would delegate onto the store. So you user
>>>>> could specialize eGet itself and handle the <X> feature in some
>>>>> special way. I.e., normally you generate eGet to call getX and
>>>>> specialize that; with reflective delegation, getX calles eGet,
>>>>> which isn't generated at all so you'd specialize that.
>>>> that would certainly work. But I afraid I would have a hard time
>>>> explaining them why they should not specialize the generated
>>>> feature methods (getX/setX) but instead create and specialize the
>>>> reflective eGet(<X>)/eSet(<X>) methods that delegate to their
>>>> getX()/setX() methods. I will investigate deeper and try to find a
>>>> way to let the user specialize the getX()/setX() methods.
>>>>
>>>>>>
>>>>>> To back EMF with the Java Content Repository I use the EStore API
>>>>>> already to facilitate lazy loading. This is why I set the feature
>>>>>> delegation to reflective and all EClasses inherit from my EStore
>>>>>> instead of EObject. Now I would like to tell my API users that
>>>>>> they can use
>>>>> But by "use", you do you mean call them (which works file) or
>>>>> specialize their code (which is not sufficient because EMF
>>>>> reflection will never call those methods).
>>>> I mean specialize the code.
>>>>
>>>> Bye,
>>>>
>>>> Sandro
>>>>
>>>>>> the generated getX/setX methods directly or they can use the
>>>>>> reflective API of EMF while the logic they implemented in the
>>>>>> getX/setX methods will always be used. Is this a valid use case
>>>>>> of EMF?
>>>>> I'd certainly not something I've ever explored...
>>>>>>
>>>>>> Bye,
>>>>>>
>>>>>> Sandro
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Sandro,
>>>>>>>
>>>>>>> The idea is to use the reflective delegation while settings the
>>>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>>>> delegate to the store (or the dynamic object's array of feature
>>>>>>> value holders) to get the value. If you call eGet directly, the
>>>>>>> process is shortcut. So the generate API is just a facade over
>>>>>>> the reflective one...
>>>>>>>
>>>>>>>
>>>>>>> Sandro Böhme wrote:
>>>>>>>> Hi Ed,
>>>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>>>
>>>>>>>> Ed Merks schrieb:
>>>>>>>>> Sandro,
>>>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>> Sandro Böhme wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> when generating an ecore model with the "Reflective" flag set
>>>>>>>>>> for
>>>>>>>>>> "Feature Delegation" the generated methods for my features
>>>>>>>>>> are not
>>>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>>>> Thus if I
>>>>>>>>>> would change the behavior of my features in the generated
>>>>>>>>>> methods it
>>>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>>>> this just a
>>>>>>>>>> bug or is it the way it should work?
>>>>>>>>> Yes, that's how it should work. An advantage of this approach
>>>>>>>>> is that it produces very little byte code. It also allows for
>>>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>>>> I tried to change the Class.javajet to generate the eSet()
>>>>>>>>>> and eGet() methods similar to "Feature Delegation"="None" and
>>>>>>>>>> the features to call super.eGet and super.eSet but this adds
>>>>>>>>>> a circular dependency and does not work. If it's a bug there
>>>>>>>>>> doesn't seem to be an easy fix.
>>>>>>>>> I guess I'm wondering what you're trying to achieve? There's
>>>>>>>>> the normal
>>>>>>>> I just tried to find a way to keep the CPU busy. Thus the
>>>>>>>> circular delegation. Life would just be boring for the CPU in
>>>>>>>> my application ;-).
>>>>>>>>
>>>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>>>> generated getX() method is just never reached when using the
>>>>>>>> generated editor plugin and it looked like it never could reach
>>>>>>>> it. Am I supposed to
>>>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>>>> store? At the moment I have no idea how that could be done when
>>>>>>>> the reflective mechanism works the other way around.
>>>>>>>>
>>>>>>>>> pattern where the reflective methods generate to your
>>>>>>>>> generated hand-modifiable methods and the reflective pattern
>>>>>>>>> that does the exact opposite. It seems you need to pick one
>>>>>>>>> of the two, and that the third choice is circular delegation,
>>>>>>>>> which seems not so useful. :-P
>>>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Sandro
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Sandro
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Reflective Feature Delegation: Reflective methods don't call the generated get/set methods? [message #419442 is a reply to message #419254] |
Thu, 22 May 2008 14:36 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Just as a reference for the archive. I opened #232414.
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=232414
Best,
Sandro
Ed Merks schrieb:
> Sandro,
>
> Yes, a bugzilla enhancement request is a good idea because otherwise I'm
> unlikely to remember the issue needs attention.
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> if you want, I can open a bug for that.
>>
>> Bye,
>> Sandro
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> I still need to look very closely, and it's weekend, but I wonder if
>>> calling eDynamicGet(int, EStructuralFeature, boolean, boolean)
>>> wouldn't be equivalent but better performing.
>>>
>>>
>>> Sandro Böhme wrote:
>>>> Hi Ed,
>>>>
>>>> after stumbling over a solution that only speeded up the circular
>>>> delegation I can come up with a solution that at least works for me.
>>>> I'm not sure if it's also applicable for others and what other
>>>> implications it has. I changed the Class.javajet to generate the
>>>> following for Feature Delegation="Reflective":
>>>>
>>>> public void setTitle(String newTitle) {
>>>> super.eSet(PackageNamePackage.BOOK__TITLE, newTitle);
>>>> }
>>>>
>>>>
>>>> public String getTitle() {
>>>> return (String)super.eGet(PackageNamePackage.BOOK__TITLE,true,
>>>> true);
>>>> }
>>>> The eGet() and eSet() methods are generated equal to Feature
>>>> Delegation="None".
>>>>
>>>> Attached you find the patch for Class.javajet to see what I changed
>>>> there.
>>>>
>>>> The result is that getX()/setX() calls the generated reflective
>>>> methods of all super classes until it ends up in
>>>> BasicEObjectImpl.eGet(featureID, resolve, coreType) and
>>>> BasicEObjectImpl.eSet(featureID, newValue)
>>>>
>>>> ++ Downside ++
>>>> One downside is, that it's wasted time to walk up the whole
>>>> inheritance hierachy as the right feature is already called and it's
>>>> not needed to search for it while walking up the hierarchy.
>>>> The method
>>>> BasicEObjectImpl.eGet(EStructuralFeature eFeature, boolean resolve,
>>>> boolean coreType) is skipped which basically means that
>>>> BasicEObjectImpl.eOpenGet(eFeature, resolve) would never get called
>>>> for getX()/setX() methods. This will probably raise problems too.
>>>> But I don't know what the use case for this method is.
>>>>
>>>> ++ Upside ++
>>>> The upside is, that one can say that a specialized model with
>>>> feature delegation set to "Reflective" behaves equal no matter if
>>>> it's accessed directly with the getX()/setX() methods or if it's
>>>> accessed reflectively with the eGet(<X>)/eSet(<X>) methods. My
>>>> understanding of EMF is, that this is an important goal.
>>>>
>>>> What do you think?
>>>>
>>>> Ciao,
>>>>
>>>> Sandro
>>>>
>>>>
>>>> Sandro Böhme schrieb:
>>>>> Hi Ed,
>>>>>
>>>>> please see my comments inline.
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Sandro,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Sandro Böhme wrote:
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> it's clear to me how it works in this direction. My understanding
>>>>>>> is just, that it's possible with EMF to work the other way around
>>>>>>> too. That the reflective API can call the generated getX()/setX()
>>>>>>> methods when setting the feature delegation to "Reflective". But
>>>>>>> I'm probably simply wrong with that.
>>>>>> No. I'm having trouble imagining what the pattern would look
>>>>>> like. With the normal pattern calling eGet(<X>) would call getX()
>>>>>> which returns the value of a variable, or could be specialized to
>>>>>> do something funky. With reflective delegation calling getX would
>>>>>> call eGet(<X>) which would delegate onto the store. So you user
>>>>>> could specialize eGet itself and handle the <X> feature in some
>>>>>> special way. I.e., normally you generate eGet to call getX and
>>>>>> specialize that; with reflective delegation, getX calles eGet,
>>>>>> which isn't generated at all so you'd specialize that.
>>>>> that would certainly work. But I afraid I would have a hard time
>>>>> explaining them why they should not specialize the generated
>>>>> feature methods (getX/setX) but instead create and specialize the
>>>>> reflective eGet(<X>)/eSet(<X>) methods that delegate to their
>>>>> getX()/setX() methods. I will investigate deeper and try to find a
>>>>> way to let the user specialize the getX()/setX() methods.
>>>>>
>>>>>>>
>>>>>>> To back EMF with the Java Content Repository I use the EStore API
>>>>>>> already to facilitate lazy loading. This is why I set the feature
>>>>>>> delegation to reflective and all EClasses inherit from my EStore
>>>>>>> instead of EObject. Now I would like to tell my API users that
>>>>>>> they can use
>>>>>> But by "use", you do you mean call them (which works file) or
>>>>>> specialize their code (which is not sufficient because EMF
>>>>>> reflection will never call those methods).
>>>>> I mean specialize the code.
>>>>>
>>>>> Bye,
>>>>>
>>>>> Sandro
>>>>>
>>>>>>> the generated getX/setX methods directly or they can use the
>>>>>>> reflective API of EMF while the logic they implemented in the
>>>>>>> getX/setX methods will always be used. Is this a valid use case
>>>>>>> of EMF?
>>>>>> I'd certainly not something I've ever explored...
>>>>>>>
>>>>>>> Bye,
>>>>>>>
>>>>>>> Sandro
>>>>>>>
>>>>>>> Ed Merks schrieb:
>>>>>>>> Sandro,
>>>>>>>>
>>>>>>>> The idea is to use the reflective delegation while settings the
>>>>>>>> root extends class to DynamicEObjectImpl or EStoreEObjectImpl.
>>>>>>>> Calling getX in the API will call eGet(<X-feature>) which will
>>>>>>>> delegate to the store (or the dynamic object's array of feature
>>>>>>>> value holders) to get the value. If you call eGet directly, the
>>>>>>>> process is shortcut. So the generate API is just a facade over
>>>>>>>> the reflective one...
>>>>>>>>
>>>>>>>>
>>>>>>>> Sandro Böhme wrote:
>>>>>>>>> Hi Ed,
>>>>>>>>> thanks for your feedback, please see my reply inline:
>>>>>>>>>
>>>>>>>>> Ed Merks schrieb:
>>>>>>>>>> Sandro,
>>>>>>>>>>
>>>>>>>>>> Comments below.
>>>>>>>>>>
>>>>>>>>>> Sandro Böhme wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> when generating an ecore model with the "Reflective" flag set
>>>>>>>>>>> for
>>>>>>>>>>> "Feature Delegation" the generated methods for my features
>>>>>>>>>>> are not
>>>>>>>>>>> getting called on the reflective eGet() and eSet() methods.
>>>>>>>>>> Yes, the delegation is in the other direction. I.e., the
>>>>>>>>>> generated getX calls eGet(<X-feature).
>>>>>>>>>>> Thus if I
>>>>>>>>>>> would change the behavior of my features in the generated
>>>>>>>>>>> methods it
>>>>>>>>>>> would not be usable when working with the reflective API. Is
>>>>>>>>>>> this just a
>>>>>>>>>>> bug or is it the way it should work?
>>>>>>>>>> Yes, that's how it should work. An advantage of this approach
>>>>>>>>>> is that it produces very little byte code. It also allows for
>>>>>>>>>> things like delegating onto a store-backed implementation.
>>>>>>>>>>> I tried to change the Class.javajet to generate the eSet()
>>>>>>>>>>> and eGet() methods similar to "Feature Delegation"="None" and
>>>>>>>>>>> the features to call super.eGet and super.eSet but this adds
>>>>>>>>>>> a circular dependency and does not work. If it's a bug there
>>>>>>>>>>> doesn't seem to be an easy fix.
>>>>>>>>>> I guess I'm wondering what you're trying to achieve? There's
>>>>>>>>>> the normal
>>>>>>>>> I just tried to find a way to keep the CPU busy. Thus the
>>>>>>>>> circular delegation. Life would just be boring for the CPU in
>>>>>>>>> my application ;-).
>>>>>>>>>
>>>>>>>>> Actually I don't do something special. The breakpoint in the
>>>>>>>>> generated getX() method is just never reached when using the
>>>>>>>>> generated editor plugin and it looked like it never could reach
>>>>>>>>> it. Am I supposed to
>>>>>>>>> call the generated getX() / setX() methods in some way in my
>>>>>>>>> store? At the moment I have no idea how that could be done when
>>>>>>>>> the reflective mechanism works the other way around.
>>>>>>>>>
>>>>>>>>>> pattern where the reflective methods generate to your
>>>>>>>>>> generated hand-modifiable methods and the reflective pattern
>>>>>>>>>> that does the exact opposite. It seems you need to pick one
>>>>>>>>>> of the two, and that the third choice is circular delegation,
>>>>>>>>>> which seems not so useful. :-P
>>>>>>>>>>> Thanks in advance for any feedback.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> Sandro
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Sandro
>>>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 20:21:33 GMT 2024
Powered by FUDForum. Page generated in 0.04336 seconds |
] 
Search
Help
Register
Login
Home
