|
|
|
|
| Re: Generator problem with Reflective Delegation [message #427461 is a reply to message #427453] |
Wed, 18 February 2009 13:26   |
|
Ed,
As you can imagine I'm trying to do some research on how easy it is to
bring reflective delegation into existing models. And have a bit fun
with shared GMF editing as well :P
I'm just explaining this to open a new perspective for requirements. for
a new model from scratch I understand your point. For somebody who wants
to get a reflective model as quickly as possible it could be nice if the
generator recognizes these cases and does "something" that works out of
the box. Couldn't the generator distinguish these two cases?
A similar issue with the default values. Not needed in a fresh model.
But if you already have handwritten code that was based on the
non-reflective implementation, again, it would be nice if these
constants would stay. I could even imagine that handwritten additions to
new reflective models might want to use the default values...
Cheers
/Eike
----
http://thegordian.blogspot.com
Ed Merks schrieb:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>> Hi,
>>
>> I'm playing with the GMF notation model and reflective feature
>> delegation.
>> GMF overwrites some eSet() and eUnset() methods with the "xyzGen()"
>> pattern.
>> With reflective delegation the generator just removes the xyzGen()
>> methods completely.
>> Is this behaviour intended?
> Well yes, we don't need to generate these reflective methods since the
> one in BasicEObjectImpl is sufficient.
>>
>> It would work nicely in my example if these methods would just reside
>> where they are...
> I suppose one could generate a stub that calls super, but that seems
> entirely pointless.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Generator problem with Reflective Delegation [message #427462 is a reply to message #427461] |
Wed, 18 February 2009 13:44 |
|
Oh, that reminds me that I wanted to ask you to change the custom code
in the EXTLibrary example.
There I realized that the handwritten bodies of 2 (?) derived features
use the instance fields directly instead of calling the getters.
If I was not mistaken it should be possible to simply change that and
give good precedence ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Eike Stepper schrieb:
> Ed,
>
> As you can imagine I'm trying to do some research on how easy it is to
> bring reflective delegation into existing models. And have a bit fun
> with shared GMF editing as well :P
> I'm just explaining this to open a new perspective for requirements.
> for a new model from scratch I understand your point. For somebody who
> wants to get a reflective model as quickly as possible it could be
> nice if the generator recognizes these cases and does "something" that
> works out of the box. Couldn't the generator distinguish these two cases?
>
> A similar issue with the default values. Not needed in a fresh model.
> But if you already have handwritten code that was based on the
> non-reflective implementation, again, it would be nice if these
> constants would stay. I could even imagine that handwritten additions
> to new reflective models might want to use the default values...
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
>
> Ed Merks schrieb:
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>> Hi,
>>>
>>> I'm playing with the GMF notation model and reflective feature
>>> delegation.
>>> GMF overwrites some eSet() and eUnset() methods with the "xyzGen()"
>>> pattern.
>>> With reflective delegation the generator just removes the xyzGen()
>>> methods completely.
>>> Is this behaviour intended?
>> Well yes, we don't need to generate these reflective methods since
>> the one in BasicEObjectImpl is sufficient.
>>>
>>> It would work nicely in my example if these methods would just
>>> reside where they are...
>> I suppose one could generate a stub that calls super, but that seems
>> entirely pointless.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Generator problem with Reflective Delegation [message #427466 is a reply to message #427462] |
Wed, 18 February 2009 15:19 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eike,
Patches for improvements are welcome.
Eike Stepper wrote:
> Oh, that reminds me that I wanted to ask you to change the custom code
> in the EXTLibrary example.
> There I realized that the handwritten bodies of 2 (?) derived features
> use the instance fields directly instead of calling the getters.
> If I was not mistaken it should be possible to simply change that and
> give good precedence ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Eike Stepper schrieb:
>> Ed,
>>
>> As you can imagine I'm trying to do some research on how easy it is
>> to bring reflective delegation into existing models. And have a bit
>> fun with shared GMF editing as well :P
>> I'm just explaining this to open a new perspective for requirements.
>> for a new model from scratch I understand your point. For somebody
>> who wants to get a reflective model as quickly as possible it could
>> be nice if the generator recognizes these cases and does "something"
>> that works out of the box. Couldn't the generator distinguish these
>> two cases?
>>
>> A similar issue with the default values. Not needed in a fresh model.
>> But if you already have handwritten code that was based on the
>> non-reflective implementation, again, it would be nice if these
>> constants would stay. I could even imagine that handwritten additions
>> to new reflective models might want to use the default values...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Eike,
>>>
>>> Comments below.
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> I'm playing with the GMF notation model and reflective feature
>>>> delegation.
>>>> GMF overwrites some eSet() and eUnset() methods with the "xyzGen()"
>>>> pattern.
>>>> With reflective delegation the generator just removes the xyzGen()
>>>> methods completely.
>>>> Is this behaviour intended?
>>> Well yes, we don't need to generate these reflective methods since
>>> the one in BasicEObjectImpl is sufficient.
>>>>
>>>> It would work nicely in my example if these methods would just
>>>> reside where they are...
>>> I suppose one could generate a stub that calls super, but that seems
>>> entirely pointless.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generator problem with Reflective Delegation [message #427467 is a reply to message #427461] |
Wed, 18 February 2009 15:21 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eike,
Comments below.
Eike Stepper wrote:
> Ed,
>
> As you can imagine I'm trying to do some research on how easy it is to
> bring reflective delegation into existing models. And have a bit fun
> with shared GMF editing as well :P
> I'm just explaining this to open a new perspective for requirements.
> for a new model from scratch I understand your point. For somebody who
> wants to get a reflective model as quickly as possible it could be
> nice if the generator recognizes these cases and does "something" that
> works out of the box. Couldn't the generator distinguish these two cases?
The generator just generated completely new .java files and later they
are merged, so no.
>
> A similar issue with the default values. Not needed in a fresh model.
> But if you already have handwritten code that was based on the
> non-reflective implementation, again, it would be nice if these
> constants would stay. I could even imagine that handwritten additions
> to new reflective models might want to use the default values...
It's hard to do the nicest thing for all possible clients. Reducing byte
code is a goal for many as well.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
>
> Ed Merks schrieb:
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>> Hi,
>>>
>>> I'm playing with the GMF notation model and reflective feature
>>> delegation.
>>> GMF overwrites some eSet() and eUnset() methods with the "xyzGen()"
>>> pattern.
>>> With reflective delegation the generator just removes the xyzGen()
>>> methods completely.
>>> Is this behaviour intended?
>> Well yes, we don't need to generate these reflective methods since
>> the one in BasicEObjectImpl is sufficient.
>>>
>>> It would work nicely in my example if these methods would just
>>> reside where they are...
>> I suppose one could generate a stub that calls super, but that seems
>> entirely pointless.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generator problem with Reflective Delegation [message #427468 is a reply to message #427467] |
Wed, 18 February 2009 15:21 |
|
Agreed ;-(
Cheers
/Eike
----
http://thegordian.blogspot.com
Ed Merks schrieb:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>> Ed,
>>
>> As you can imagine I'm trying to do some research on how easy it is
>> to bring reflective delegation into existing models. And have a bit
>> fun with shared GMF editing as well :P
>> I'm just explaining this to open a new perspective for requirements.
>> for a new model from scratch I understand your point. For somebody
>> who wants to get a reflective model as quickly as possible it could
>> be nice if the generator recognizes these cases and does "something"
>> that works out of the box. Couldn't the generator distinguish these
>> two cases?
> The generator just generated completely new .java files and later they
> are merged, so no.
>>
>> A similar issue with the default values. Not needed in a fresh model.
>> But if you already have handwritten code that was based on the
>> non-reflective implementation, again, it would be nice if these
>> constants would stay. I could even imagine that handwritten additions
>> to new reflective models might want to use the default values...
> It's hard to do the nicest thing for all possible clients. Reducing
> byte code is a goal for many as well.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Eike,
>>>
>>> Comments below.
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> I'm playing with the GMF notation model and reflective feature
>>>> delegation.
>>>> GMF overwrites some eSet() and eUnset() methods with the "xyzGen()"
>>>> pattern.
>>>> With reflective delegation the generator just removes the xyzGen()
>>>> methods completely.
>>>> Is this behaviour intended?
>>> Well yes, we don't need to generate these reflective methods since
>>> the one in BasicEObjectImpl is sufficient.
>>>>
>>>> It would work nicely in my example if these methods would just
>>>> reside where they are...
>>> I suppose one could generate a stub that calls super, but that seems
>>> entirely pointless.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03546 seconds
] 
Search
Help
Register
Login
Home
