Home » Modeling » EMF » xyzGen methods that call super should call super.xyzGen
| xyzGen methods that call super should call super.xyzGen [message #527795] |
Fri, 16 April 2010 14:03  |
|
Hi,
In my model, I am customizing the notifyChanged() method of some edit
providers. So, I am following the common pattern of renaming
notifyChanged() to notifyChangedGen() and calling it from my custom
notifyChanged() implementation.
So far, so good.
The problem comes when I do similar customization of notifyChanged() in
subclasses edit provider in which I have a notifyChangedGen(). My
subclass notifyChanged() calls super.notifyChanged() to inherit custom
behaviour and my subclass notifyChangedGen has to call
super.notifyChangedGen() to inherit the default behaviour. However, EMF
re-generates my subclass notifyChangedGen() to call
super.notifyChanged(), which calls notifyChangedGen(), resulting in
Stack Overflow.
I think the codegen templates need to check, when they detect an xyzGen
rename, whether the superclass also has xyzGen. In that case, a call to
super.xyzGen would be more appropriate than super.xyz. Keep the
generated code chained together and the custom code chained together.
Otherwise, the xyzGen pattern just doesn't work.
Or, am I doing something wrong?
Thanks,
Christian
|
|
|
| Re: xyzGen methods that call super should call super.xyzGen [message #527796 is a reply to message #527795] |
Fri, 16 April 2010 14:09  |
 Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020801070007030806070602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
The handling of redirecting to a Gen method is done directly by JMerge;
it's not in the templates. I'm not sure it's reasonable to expect it to
detect calls to super *and *for it to assume that in fact there is a Gen
method in the super class. That won't always be the case, right? Isn't
it possible to make the Gen method private to address this issue?
Christian W. Damus wrote:
> Hi,
>
> In my model, I am customizing the notifyChanged() method of some edit
> providers. So, I am following the common pattern of renaming
> notifyChanged() to notifyChangedGen() and calling it from my custom
> notifyChanged() implementation.
>
> So far, so good.
>
> The problem comes when I do similar customization of notifyChanged()
> in subclasses edit provider in which I have a notifyChangedGen(). My
> subclass notifyChanged() calls super.notifyChanged() to inherit custom
> behaviour and my subclass notifyChangedGen has to call
> super.notifyChangedGen() to inherit the default behaviour. However,
> EMF re-generates my subclass notifyChangedGen() to call
> super.notifyChanged(), which calls notifyChangedGen(), resulting in
> Stack Overflow.
>
> I think the codegen templates need to check, when they detect an
> xyzGen rename, whether the superclass also has xyzGen. In that case,
> a call to super.xyzGen would be more appropriate than super.xyz. Keep
> the generated code chained together and the custom code chained
> together. Otherwise, the xyzGen pattern just doesn't work.
>
> Or, am I doing something wrong?
>
> Thanks,
>
> Christian
--------------020801070007030806070602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
The handling of redirecting to a Gen method is done directly by JMerge;
it's not in the templates. I'm not sure it's reasonable to expect it
to detect calls to super <b>and </b>for it to assume that in fact
there is a Gen method in the super class. That won't always be the
case, right? Isn't it possible to make the Gen method private to
address this issue?<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:hq9qn4$hl2$1@build.eclipse.org" type="cite">Hi,
<br>
<br>
In my model, I am customizing the notifyChanged() method of some edit
providers. So, I am following the common pattern of renaming
notifyChanged() to notifyChangedGen() and calling it from my custom
notifyChanged() implementation.
<br>
<br>
So far, so good.
<br>
<br>
The problem comes when I do similar customization of notifyChanged() in
subclasses edit provider in which I have a notifyChangedGen(). My
subclass notifyChanged() calls super.notifyChanged() to inherit custom
behaviour and my subclass notifyChangedGen has to call
super.notifyChangedGen() to inherit the default behaviour. However,
EMF re-generates my subclass notifyChangedGen() to call
super.notifyChanged(), which calls notifyChangedGen(), resulting in
Stack Overflow.
<br>
<br>
I think the codegen templates need to check, when they detect an xyzGen
rename, whether the superclass also has xyzGen. In that case, a call
to super.xyzGen would be more appropriate than super.xyz. Keep the
generated code chained together and the custom code chained together.
Otherwise, the xyzGen pattern just doesn't work.
<br>
<br>
Or, am I doing something wrong?
<br>
<br>
Thanks,
<br>
<br>
Christian
<br>
</blockquote>
</body>
</html>
--------------020801070007030806070602--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: xyzGen methods that call super should call super.xyzGen [message #527808 is a reply to message #527796] |
Fri, 16 April 2010 14:45 |
|
Hi, Ed,
I just knew I must be doing something wrong! I didn't read the EMF book
.... :-)
I didn't realize that it's a JMerge feature. I thought the code
generator would be able to check whether the superclass has an xyzGen,
but if it's in JMerge, then I can understand that this might be more
difficult.
Making the xyzGen private worked swimmingly. I did a regex
search-and-replace to make all of my xyzGens private and change my xyzs
to always call their own xyzGen partner. The problem was only that the
superclass's call from xyz to xyzGen is dynamically bound, which causes
the oscillation. But private methods are statically bound.
For some reason I didn't consider that I could change the visibility of
the xyzGen method. Silly me! Thanks, Ed.
cW
On 16/04/10 10:09 AM, Ed Merks wrote:
> Christian,
>
> The handling of redirecting to a Gen method is done directly by JMerge;
> it's not in the templates. I'm not sure it's reasonable to expect it to
> detect calls to super *and *for it to assume that in fact there is a Gen
> method in the super class. That won't always be the case, right? Isn't
> it possible to make the Gen method private to address this issue?
------8<------
|
|
|
| Re: xyzGen methods that call super should call super.xyzGen [message #527843 is a reply to message #527808] |
Fri, 16 April 2010 15:52 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Christian,
It's not as if it's all totally obvious. I seem to recall it was Rich
Kulp who pointed out the advantages of making the Gen method private and
as a result we changed the merger not to mess with the access declared
in the target.
Christian W. Damus wrote:
> Hi, Ed,
>
> I just knew I must be doing something wrong! I didn't read the EMF
> book ... :-)
>
> I didn't realize that it's a JMerge feature. I thought the code
> generator would be able to check whether the superclass has an xyzGen,
> but if it's in JMerge, then I can understand that this might be more
> difficult.
>
> Making the xyzGen private worked swimmingly. I did a regex
> search-and-replace to make all of my xyzGens private and change my
> xyzs to always call their own xyzGen partner. The problem was only
> that the superclass's call from xyz to xyzGen is dynamically bound,
> which causes the oscillation. But private methods are statically bound.
>
> For some reason I didn't consider that I could change the visibility
> of the xyzGen method. Silly me! Thanks, Ed.
>
> cW
>
>
> On 16/04/10 10:09 AM, Ed Merks wrote:
>> Christian,
>>
>> The handling of redirecting to a Gen method is done directly by JMerge;
>> it's not in the templates. I'm not sure it's reasonable to expect it to
>> detect calls to super *and *for it to assume that in fact there is a Gen
>> method in the super class. That won't always be the case, right? Isn't
>> it possible to make the Gen method private to address this issue?
>
> ------8<------
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Sep 26 06:42:32 GMT 2024
Powered by FUDForum. Page generated in 0.04260 seconds |
] 
Search
Help
Register
Login
Home
