Home » Modeling » EMF » modify generated code or subclass?
|
| Re: modify generated code or subclass? [message #423203 is a reply to message #423200] |
Wed, 24 September 2008 18:34   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
André,
Comments below.
André Dietisheim wrote:
> Hi!
>
> I'm currently slowly getting into EMF and modelling in general.
Isn't life grand?!
> I wonder if it conforms to the best pratice to modify the generated code.
Certainly there will be those with opinions different from my own. I'll
characterize myself as a pragmatist and those who disagree with me as
purists. That's sure to raise their ire. :-P
> I read several times about good pratices in modelling that advise to
> separate generated from hand written code.
I can imagine that's often a very good approach, but in real life, it's
not always such a great approach.
> AndroMDA, I expericenced a bit, used to generate abstract super- and
> empty subclasses that could filled with handwritten code.
Yes, but what if you need to add things to your interface and then also
add things to your implementation classes. When we started the EMF work
we used to have a "four class pattern". A purely generated interface
that extends a user modifiable empty interface and then a pair of
classes (or something gross like that). Lots of extra classes with
associated byte code overhead. Another drawback of this approach is
that the image in CVS isn't complete until you run a generator, so
everyone must have the generator tools around in order to be able to
work with your source code. And of course with EMF, we generate the
generator, so we'd have a chicken and egg problem if we didn't version
the generated source.
> I therefore wonder what are the advices the old hands at EMF could
> give me. Just don't bother that much? ;-)
In my opinion, at least in the context of generated EMF code, I'd highly
recommend you version all your generated artifacts in CVS or
Subversion. Modify the code as you see fit, but try to stick to using
the "Gen" pattern approach as much as possible. I.e., if you want to
modify a method foo, renamed it too fooGen and put your change in a new
version of foo that calls fooGen; this is must like overriding a method
in a derived class and calling super.
Anything you add that's not marked @generated will be preserved, so
don't worry about that. Anything that is @generated that you really do
want to modify, mark it with @generated NOT so you'll know it was
generated but you changed it.
Whenever you regenerate and things change, the team support in Eclipse
will let you review those changes, take responsibility for all changes
as if you wrote them yourself.
>
> Thanks
> André
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: modify generated code or subclass? [message #423222 is a reply to message #423203] |
Thu, 25 September 2008 08:25 |
Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Ed!
thanks for the exhaustive answer and the insights!
>> I wonder if it conforms to the best pratice to modify the generated code.
> Certainly there will be those with opinions different from my own. I'll
> characterize myself as a pragmatist and those who disagree with me as
> purists. That's sure to raise their ire. :-P
I would have guessed - by the 'puristic' photos on your blog - that
you're a purist ;-)
>> I read several times about good pratices in modelling that advise to
>> separate generated from hand written code.
> I can imagine that's often a very good approach, but in real life, it's
> not always such a great approach.
>> AndroMDA, I expericenced a bit, used to generate abstract super- and
>> empty subclasses that could filled with handwritten code.
> Yes, but what if you need to add things to your interface and then also
> add things to your implementation classes. When we started the EMF work
> we used to have a "four class pattern". A purely generated interface
> that extends a user modifiable empty interface and then a pair of
> classes (or something gross like that). Lots of extra classes with
> associated byte code overhead. Another drawback of this approach is
> that the image in CVS isn't complete until you run a generator, so
> everyone must have the generator tools around in order to be able to
> work with your source code. And of course with EMF, we generate the
> generator, so we'd have a chicken and egg problem if we didn't version
> the generated source.
I have to admit that I usually tend to be a purist. What I am looking
for is less optimal bytecode nor execution but a clean structure, good
readability etc. That led me to split handwritten and generated code. I
agree that the large amount of artifact's not optimal either but I
usually preferred it.
If I hear that you started with a 4 classes pattern I see that you
already went all the way up I just started to follow. So I'll stick to
your advice and modify generated code and checkin it in to my scm.
>> I therefore wonder what are the advices the old hands at EMF could
>> give me. Just don't bother that much? ;-)
> In my opinion, at least in the context of generated EMF code, I'd highly
> recommend you version all your generated artifacts in CVS or
> Subversion.
The main difference to my laste experiences when generating code was
that the generator did not merge as well as EMF does. I assume that you
built these merging capabilities when you choose to modify generated code.
> Modify the code as you see fit, but try to stick to using
> the "Gen" pattern approach as much as possible. I.e., if you want to
> modify a method foo, renamed it too fooGen and put your change in a new
> version of foo that calls fooGen; this is must like overriding a method
> in a derived class and calling super.
>
> Anything you add that's not marked @generated will be preserved, so
> don't worry about that. Anything that is @generated that you really do
> want to modify, mark it with @generated NOT so you'll know it was
> generated but you changed it.
>
> Whenever you regenerate and things change, the team support in Eclipse
> will let you review those changes, take responsibility for all changes
> as if you wrote them yourself.
>>
One last question: is there any facility that does highlight generated /
handwritten code parts in Eclipse? I saw that Mint already does supply
some help here.
Thanks!
André
|
|
|
| Re: modify generated code or subclass? [message #423230 is a reply to message #423222] |
Thu, 25 September 2008 10:34 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
André,
Comments below.
André Dietisheim wrote:
> Hi Ed!
>
> thanks for the exhaustive answer and the insights!
>
>>> I wonder if it conforms to the best pratice to modify the generated
>>> code.
>> Certainly there will be those with opinions different from my own.
>> I'll characterize myself as a pragmatist and those who disagree with
>> me as purists. That's sure to raise their ire. :-P
>
> I would have guessed - by the 'puristic' photos on your blog - that
> you're a purist ;-)
Touche.
>
>>> I read several times about good pratices in modelling that advise to
>>> separate generated from hand written code.
>> I can imagine that's often a very good approach, but in real life,
>> it's not always such a great approach.
>>> AndroMDA, I expericenced a bit, used to generate abstract super-
>>> and empty subclasses that could filled with handwritten code.
>> Yes, but what if you need to add things to your interface and then
>> also add things to your implementation classes. When we started the
>> EMF work we used to have a "four class pattern". A purely generated
>> interface that extends a user modifiable empty interface and then a
>> pair of classes (or something gross like that). Lots of extra
>> classes with associated byte code overhead. Another drawback of
>> this approach is that the image in CVS isn't complete until you run a
>> generator, so everyone must have the generator tools around in order
>> to be able to work with your source code. And of course with EMF,
>> we generate the generator, so we'd have a chicken and egg problem if
>> we didn't version the generated source.
>
> I have to admit that I usually tend to be a purist. What I am looking
> for is less optimal bytecode nor execution but a clean structure, good
> readability etc.
Personally I'm not convinced that doubling the number of classes
enhances anything, especially not doubling the number of interfaces.
All clients will see that little tidbit. The Mint tools have quite nice
filtering capability that would let you view a .java file hiding all the
@generated things. So this readability issue is easily addresses with
some simple filtering rather than wholesale restructuring of the source.
> That led me to split handwritten and generated code. I agree that the
> large amount of artifact's not optimal either but I usually preferred it.
> If I hear that you started with a 4 classes pattern I see that you
> already went all the way up I just started to follow. So I'll stick to
> your advice and modify generated code and checkin it in to my scm.
I think that generally people consuming your code will be happier that
the source controlled image is complete. It will also give you a better
sense of how generator changes might impact you. I.e., you'll see when
the generator changes your code and can take action based on that rather
than treating the generated code like a black box...
>
>>> I therefore wonder what are the advices the old hands at EMF could
>>> give me. Just don't bother that much? ;-)
>> In my opinion, at least in the context of generated EMF code, I'd
>> highly recommend you version all your generated artifacts in CVS or
>> Subversion.
>
> The main difference to my laste experiences when generating code was
> that the generator did not merge as well as EMF does. I assume that
> you built these merging capabilities when you choose to modify
> generated code.
Absolutely. Without proper support for merging, the option to modify
generated code is terrible. The only real danger is modifying an
@generated method, forgetting to add the "NOT", and then regenerating
which loses your hand written changes. Of course Eclipse has a nice
history mechanism by which you can recover them, and if you have your
code committed before you generate, the Eclipse's team support is great
for drawing your attention to all the changed files. Of course we only
write out a file if it's actually changed, so you won't get deltas on
all files just because you've regenerated.
>
>> Modify the code as you see fit, but try to stick to using the "Gen"
>> pattern approach as much as possible. I.e., if you want to modify a
>> method foo, renamed it too fooGen and put your change in a new
>> version of foo that calls fooGen; this is must like overriding a
>> method in a derived class and calling super.
>>
>> Anything you add that's not marked @generated will be preserved, so
>> don't worry about that. Anything that is @generated that you really
>> do want to modify, mark it with @generated NOT so you'll know it was
>> generated but you changed it.
>>
>> Whenever you regenerate and things change, the team support in
>> Eclipse will let you review those changes, take responsibility for
>> all changes as if you wrote them yourself.
>>>
>
> One last question: is there any facility that does highlight generated
> / handwritten code parts in Eclipse? I saw that Mint already does
> supply some help here.
Yes, Mint lets you filter out all the @generated stuff, so you can
effectively view your file as if you'd separated all the hand written
stuff in a separate file...
>
> Thanks!
> André
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: modify generated code or subclass? [message #423279 is a reply to message #423200] |
Thu, 25 September 2008 20:34 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
André Dietisheim wrote:
> Hi!
>
> I'm currently slowly getting into EMF and modelling in general. I wonder
> if it conforms to the best pratice to modify the generated code. I read
> several times about good pratices in modelling that advise to separate
> generated from hand written code. AndroMDA, I expericenced a bit, used
> to generate abstract super- and empty subclasses that could filled with
> handwritten code. I therefore wonder what are the advices the old hands
> at EMF could give me. Just don't bother that much? ;-)
If you consider the modify generated code strategy, there is one big
gotcha that you should be aware of: it makes refactoring your model very
tedious. Renaming or moving types to other packages will cause new
classes to be generated, WITHOUT our hand-written changes. So you'll
have to manually go find all the hand-written code and move it over to
the new generated class.
From experience on our own product, we can say this is a real pain
while your model is subject to refactoring.
Eric
PS,
I'm purposefully NOT responding to Ed's post because, although I am a
purist, I refuse to be baited by him into a philosophical debate. Oh
darn, I just did...
;-)
|
|
|
| Re: modify generated code or subclass? [message #423280 is a reply to message #423279] |
Thu, 25 September 2008 20:41 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Eric,
You can also use JDT to refactor the generated code first, then
regenerate from EMF. It will merge into the new location and should
preserve your custom code.
Cheers,
Christian
Eric Rizzo wrote:
> André Dietisheim wrote:
>> Hi!
>>
>> I'm currently slowly getting into EMF and modelling in general. I
>> wonder if it conforms to the best pratice to modify the generated
>> code. I read several times about good pratices in modelling that
>> advise to separate generated from hand written code. AndroMDA, I
>> expericenced a bit, used to generate abstract super- and empty
>> subclasses that could filled with handwritten code. I therefore wonder
>> what are the advices the old hands at EMF could give me. Just don't
>> bother that much? ;-)
>
> If you consider the modify generated code strategy, there is one big
> gotcha that you should be aware of: it makes refactoring your model very
> tedious. Renaming or moving types to other packages will cause new
> classes to be generated, WITHOUT our hand-written changes. So you'll
> have to manually go find all the hand-written code and move it over to
> the new generated class.
> From experience on our own product, we can say this is a real pain
> while your model is subject to refactoring.
>
> Eric
>
> PS,
> I'm purposefully NOT responding to Ed's post because, although I am a
> purist, I refuse to be baited by him into a philosophical debate. Oh
> darn, I just did...
> ;-)
|
|
|
| Re: modify generated code or subclass? [message #423281 is a reply to message #423279] |
Thu, 25 September 2008 21:30 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Eric,
Which reminds me that there's a refactoring contribution bug I need to
review! Ooops!!
Of course one can use JDT refactoring of the Java classes first,
followed by renaming of the class in Ecore, and finally regenerating
that result to make sure the JDT refactoring did a good thing.
PS.
Purists are easily baited. I don't even need to prove my point! :-P
Hehehe.
Eric Rizzo wrote:
> André Dietisheim wrote:
>> Hi!
>>
>> I'm currently slowly getting into EMF and modelling in general. I
>> wonder if it conforms to the best pratice to modify the generated
>> code. I read several times about good pratices in modelling that
>> advise to separate generated from hand written code. AndroMDA, I
>> expericenced a bit, used to generate abstract super- and empty
>> subclasses that could filled with handwritten code. I therefore
>> wonder what are the advices the old hands at EMF could give me. Just
>> don't bother that much? ;-)
>
> If you consider the modify generated code strategy, there is one big
> gotcha that you should be aware of: it makes refactoring your model
> very tedious. Renaming or moving types to other packages will cause
> new classes to be generated, WITHOUT our hand-written changes. So
> you'll have to manually go find all the hand-written code and move it
> over to the new generated class.
> From experience on our own product, we can say this is a real pain
> while your model is subject to refactoring.
>
> Eric
>
> PS,
> I'm purposefully NOT responding to Ed's post because, although I am a
> purist, I refuse to be baited by him into a philosophical debate. Oh
> darn, I just did...
> ;-)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: modify generated code or subclass? [message #423282 is a reply to message #423280] |
Thu, 25 September 2008 21:31 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Christian,
Please don't cloud the issue with facts. That's my role!
Christian W. Damus wrote:
> Hi, Eric,
>
> You can also use JDT to refactor the generated code first, then
> regenerate from EMF. It will merge into the new location and should
> preserve your custom code.
>
> Cheers,
>
> Christian
>
>
> Eric Rizzo wrote:
>> André Dietisheim wrote:
>>> Hi!
>>>
>>> I'm currently slowly getting into EMF and modelling in general. I
>>> wonder if it conforms to the best pratice to modify the generated
>>> code. I read several times about good pratices in modelling that
>>> advise to separate generated from hand written code. AndroMDA, I
>>> expericenced a bit, used to generate abstract super- and empty
>>> subclasses that could filled with handwritten code. I therefore
>>> wonder what are the advices the old hands at EMF could give me. Just
>>> don't bother that much? ;-)
>>
>> If you consider the modify generated code strategy, there is one big
>> gotcha that you should be aware of: it makes refactoring your model
>> very tedious. Renaming or moving types to other packages will cause
>> new classes to be generated, WITHOUT our hand-written changes. So
>> you'll have to manually go find all the hand-written code and move it
>> over to the new generated class.
>> From experience on our own product, we can say this is a real pain
>> while your model is subject to refactoring.
>>
>> Eric
>>
>> PS,
>> I'm purposefully NOT responding to Ed's post because, although I am a
>> purist, I refuse to be baited by him into a philosophical debate. Oh
>> darn, I just did...
>> ;-)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: modify generated code or subclass? [message #423303 is a reply to message #423280] |
Fri, 26 September 2008 17:12 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Christian W. Damus wrote:
> Hi, Eric,
>
> You can also use JDT to refactor the generated code first, then
> regenerate from EMF. It will merge into the new location and should
> preserve your custom code.
Hmm, that's an interesting idea. I'll have to try it out the next time I
need to refactor part of our model.
Thanks,
Eric
> Eric Rizzo wrote:
>> André Dietisheim wrote:
>>> Hi!
>>>
>>> I'm currently slowly getting into EMF and modelling in general. I
>>> wonder if it conforms to the best pratice to modify the generated
>>> code. I read several times about good pratices in modelling that
>>> advise to separate generated from hand written code. AndroMDA, I
>>> expericenced a bit, used to generate abstract super- and empty
>>> subclasses that could filled with handwritten code. I therefore
>>> wonder what are the advices the old hands at EMF could give me. Just
>>> don't bother that much? ;-)
>>
>> If you consider the modify generated code strategy, there is one big
>> gotcha that you should be aware of: it makes refactoring your model
>> very tedious. Renaming or moving types to other packages will cause
>> new classes to be generated, WITHOUT our hand-written changes. So
>> you'll have to manually go find all the hand-written code and move it
>> over to the new generated class.
>> From experience on our own product, we can say this is a real pain
>> while your model is subject to refactoring.
>>
>> Eric
>>
>> PS,
>> I'm purposefully NOT responding to Ed's post because, although I am a
>> purist, I refuse to be baited by him into a philosophical debate. Oh
>> darn, I just did...
>> ;-)
|
|
|
| Re: modify generated code or subclass? [message #423304 is a reply to message #423282] |
Fri, 26 September 2008 17:15 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Christian,
>
> Please don't cloud the issue with facts. That's my role!
IMO, this topic should be brought up any time it is recommended to
someone to modify the generated code. I contend that it's not obvious
(until you've heard it, at which point it seems obvious ;-)
Eric
>
> Christian W. Damus wrote:
>> Hi, Eric,
>>
>> You can also use JDT to refactor the generated code first, then
>> regenerate from EMF. It will merge into the new location and should
>> preserve your custom code.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Eric Rizzo wrote:
>>> André Dietisheim wrote:
>>>> Hi!
>>>>
>>>> I'm currently slowly getting into EMF and modelling in general. I
>>>> wonder if it conforms to the best pratice to modify the generated
>>>> code. I read several times about good pratices in modelling that
>>>> advise to separate generated from hand written code. AndroMDA, I
>>>> expericenced a bit, used to generate abstract super- and empty
>>>> subclasses that could filled with handwritten code. I therefore
>>>> wonder what are the advices the old hands at EMF could give me. Just
>>>> don't bother that much? ;-)
>>>
>>> If you consider the modify generated code strategy, there is one big
>>> gotcha that you should be aware of: it makes refactoring your model
>>> very tedious. Renaming or moving types to other packages will cause
>>> new classes to be generated, WITHOUT our hand-written changes. So
>>> you'll have to manually go find all the hand-written code and move it
>>> over to the new generated class.
>>> From experience on our own product, we can say this is a real pain
>>> while your model is subject to refactoring.
>>>
>>> Eric
>>>
>>> PS,
>>> I'm purposefully NOT responding to Ed's post because, although I am a
>>> purist, I refuse to be baited by him into a philosophical debate. Oh
>>> darn, I just did...
>>> ;-)
|
|
|
| Re: modify generated code or subclass? [message #423336 is a reply to message #423281] |
Mon, 29 September 2008 02:14 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Now that would be nice. Refactoring that preserved your hand written code
even if you moved, renamed etc. your class in ecore.
We can dream can't we
Ed Merks wrote:
> Eric,
> Which reminds me that there's a refactoring contribution bug I need to
> review! Ooops!!
> Of course one can use JDT refactoring of the Java classes first,
> followed by renaming of the class in Ecore, and finally regenerating
> that result to make sure the JDT refactoring did a good thing.
> PS.
> Purists are easily baited. I don't even need to prove my point! :-P
> Hehehe.
> Eric Rizzo wrote:
>> André Dietisheim wrote:
>>> Hi!
>>>
>>> I'm currently slowly getting into EMF and modelling in general. I
>>> wonder if it conforms to the best pratice to modify the generated
>>> code. I read several times about good pratices in modelling that
>>> advise to separate generated from hand written code. AndroMDA, I
>>> expericenced a bit, used to generate abstract super- and empty
>>> subclasses that could filled with handwritten code. I therefore
>>> wonder what are the advices the old hands at EMF could give me. Just
>>> don't bother that much? ;-)
>>
>> If you consider the modify generated code strategy, there is one big
>> gotcha that you should be aware of: it makes refactoring your model
>> very tedious. Renaming or moving types to other packages will cause
>> new classes to be generated, WITHOUT our hand-written changes. So
>> you'll have to manually go find all the hand-written code and move it
>> over to the new generated class.
>> From experience on our own product, we can say this is a real pain
>> while your model is subject to refactoring.
>>
>> Eric
>>
>> PS,
>> I'm purposefully NOT responding to Ed's post because, although I am a
>> purist, I refuse to be baited by him into a philosophical debate. Oh
>> darn, I just did...
>> ;-)
|
|
| |
| Re: modify generated code or subclass? [message #423345 is a reply to message #423337] |
Mon, 29 September 2008 11:02 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060601060208070506000504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Bob,
As was pointed out though, if you use JDT refactoring to rename/move
your classes, the hand written changes will tag along with that
effort. Of course if we had decent development resource to make
Ecore-based modeling as slick as JDT, the tools would handle this all
for you at the click of a button; but somehow that's not been in
anyone's commercial best interests yet. In any case, it seems to me
that even if you did separate out the hand written code, you'd still
need to move those files around. Of course you'd use refactoring to
move them, but then moving them by refactoring would be no harder than
moving the combination of generated and hand written code by
refactoring... Refactoring at the model level would help with many
issues. Renaming a feature would refactor a whole bunch of related
things at once, e.g., the getter, setter, and field,
As with all things in life, architectural choices tend to have some
advantages and some disadvantages making the optimal choice not entirely
clear and subject to debate. Like the classical time-space trade-off:
sometimes it's more important to be fast, and sometimes it's more
important to be small. It's very hard to achieve both at once and
depending on the context, one might need to go either way...
Bob wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:gbgsja$571$1@build.eclipse.org...
> Andr
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:57:55 GMT 2024
Powered by FUDForum. Page generated in 0.03556 seconds |
] 
Search
Help
Register
Login
Home
