Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Separation of generated code(Generating of double-derived classes for better code-customization)
Separation of generated code [message #1062767] Mon, 10 June 2013 16:20 Go to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
I've already tried the forum search and google but I couldn't find a good answer to my question.

I'm wondering whether there are any attempts to provide better separation of generated and hand-crafted code using EMF / ecore. IMHO it is extremely painful to have one file that contains generated fragments interweaved with custom modifications and additions. Especially when using SVN or any other versioning system this is none too pleasant Confused

Unfortunately Java does not support partial classes, but it would already be a great relief if all generated classes would be "double-derived" (a term used by Microsoft in their modeling framework VMSDK): every generated class is made up of a base- and a customization class. For example, "XXXResourceImpl", which you have to modify to use UUIDs for XMI serialization, would be made up of "XXXResourceImplBase" and "XXXResourceImpl". Only the first one would contain generated code, but only the latter one would be "used" (instantiated/referenced). This would allow nearly full customization by overriding corresponding methods in "XXXResourceImpl". Even without partial classes this could already be enough to get rid of the "@generated" comment ( horrible Shocked ) completely.

Is someone working on something like this? Or is it available by using a magic switch in the genmodel I've not found yet?

I doubt that I'm the first one who asks this, but as I said I couldn't find anything...
Re: Separation of generated code [message #1062797 is a reply to message #1062767] Mon, 10 June 2013 19:16 Go to previous messageGo to next message
Mikael Barbero is currently offline Mikael BarberoFriend
Messages: 55
Registered: July 2009
Member
A common pattern when your language don't have partial classes is to use "generation gap pattern".

It is very well described in this blogpost http://heikobehrens.net/2009/04/23/generation-gap-pattern/ and I implemented a tool to help you implementing this pattern with EMF : https://github.com/mbarbero/emf-loophole

HTH.


Best regards,

Mikael Barbero
Obeo

[Updated on: Mon, 10 June 2013 19:17]

Report message to a moderator

Re: Separation of generated code [message #1062800 is a reply to message #1062767] Mon, 10 June 2013 19:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Till,

http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html

More comments below.

On 10/06/2013 6:20 PM, Till Fischer wrote:
> I've already tried the forum search and google but I couldn't find a
> good answer to my question.
>
> I'm wondering whether there are any attempts to provide better
> separation of generated and hand-crafted code using EMF / ecore. IMHO
> it is extremely painful to have one file that contains generated
> fragments interweaved with custom modifications and additions.
Why?
> Especially when using SVN or any other versioning system this is none
> too pleasant :?
How does that make it more painful?
> Unfortunately Java does not support partial classes, but it would
> already be a great relief if all generated classes would be
> "double-derived" (a term used by Microsoft in their modeling framework
> VMSDK): every generated class is made up of a base- and a
> customization class.
See the blog.
> For example, "XXXResourceImpl", which you have to modify to use UUIDs
> for XMI serialization, would be made up of "XXXResourceImplBase" and
> "XXXResourceImpl". Only the first one would contain generated code,
> but only the latter one would be "used" (instantiated/referenced).
> This would allow nearly full customization by overriding corresponding
> methods in "XXXResourceImpl". Even without partial classes this could
> already be enough to get rid of the "@generated" comment ( horrible
> 8o ) completely.
I have a different opinion. Deepening the class hierarchy has a
performance penalty both in terms of runtime and footprint.
>
> Is someone working on something like this? Or is it available by using
> a magic switch in the genmodel I've not found yet?
>
> I doubt that I'm the first one who asks this, but as I said I couldn't
> find anything...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Separation of generated code [message #1062816 is a reply to message #1062800] Mon, 10 June 2013 21:08 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
To give my 2 cents. For me it has never been a problem to mix hand written and generated code. Imo the generated code
should be committed/pushed to git/hg. I don't see why it would be more painfull, the generated code only changes if the
model changes, and I personally think it is great if these changes are reflected in the git-history.

See here for some additional arguments why it makes perfect sense (imho) to commit/push generated code to git/a cvs:
http://wiki.eclipse.org/Texo/Design_Concepts#Working_with_generated_code

gr. Martin

On 06/10/2013 09:19 PM, Ed Merks wrote:
> Till,
>
> http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
>
> More comments below.
>
> On 10/06/2013 6:20 PM, Till Fischer wrote:
>> I've already tried the forum search and google but I couldn't find a good answer to my question.
>>
>> I'm wondering whether there are any attempts to provide better separation of generated and hand-crafted code using EMF
>> / ecore. IMHO it is extremely painful to have one file that contains generated fragments interweaved with custom
>> modifications and additions.
> Why?
>> Especially when using SVN or any other versioning system this is none too pleasant :?
> How does that make it more painful?
>> Unfortunately Java does not support partial classes, but it would already be a great relief if all generated classes
>> would be "double-derived" (a term used by Microsoft in their modeling framework VMSDK): every generated class is made
>> up of a base- and a customization class.
> See the blog.
>> For example, "XXXResourceImpl", which you have to modify to use UUIDs for XMI serialization, would be made up of
>> "XXXResourceImplBase" and "XXXResourceImpl". Only the first one would contain generated code, but only the latter one
>> would be "used" (instantiated/referenced). This would allow nearly full customization by overriding corresponding
>> methods in "XXXResourceImpl". Even without partial classes this could already be enough to get rid of the "@generated"
>> comment ( horrible 8o ) completely.
> I have a different opinion. Deepening the class hierarchy has a performance penalty both in terms of runtime and
> footprint.
>>
>> Is someone working on something like this? Or is it available by using a magic switch in the genmodel I've not found yet?
>>
>> I doubt that I'm the first one who asks this, but as I said I couldn't find anything...
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Re: Separation of generated code [message #1062872 is a reply to message #1062816] Tue, 11 June 2013 08:06 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
@Mikael Barbero: didn't know the name for this design pattern. Thanks for this info! Your project seems to be exactly what I was looking for. However I think that such a core feature shouldn't be added side-by-side (additional plugin, yet another genmodel, original genmodel reference), but included in the EMF tooling... any talks with respective persons, yet?

Quote:
For me it has never been a problem to mix hand written and generated code. Imo the generated code
should be committed/pushed to git/hg. I don't see why it would be more painfull, the generated code only changes if the
model changes, and I personally think it is great if these changes are reflected in the git-history.

Changes in the model are reflected in the versioning-history by looking at the model-file in the repository. Having generated code in the repository is exactly the same like having binary files in the repository (binary data is nothing but generated code as well).

Regarding Ed's questions:

it is not only bad practice, it also adds additional maintanance cost: you have to add / delete / move / rename generated files in the repo if you change / add / remove a model, because generation tools don't manage the repository for you (of course they could, but why always adding features to tools which are not really necessary (and probably buggy)).

Why else is it bad to have mixed generated and hand-written code? Let's look at the opposite: why is it good to have separation between hand-written and generated code?

1. Because it makes everything much easier to understand! If someone else in a team has to work with your code and it is mixed with generated parts: how long do you think does he need to only understand WHAT was actually done? Assume he knows the generation tools and could identify the modified parts within seconds: the WHAT is obvious and the intention of the programmer is much clearer.

2. NO re-generation problems. All generated parts can be removed completely without doing any harm. You cannot do anything wrong. There is no need of ANY intelligence in generation tools. A valid algorithm can be as simple as that: delete everything; generate. This solves another issue: you don't have dead generated classes or functions somewhere in your code. Once again: tools could be very very very intelligent and fix everything four you, but in reality there is no need for such "feature" (which is rather complex and thereby error-prone).

3. Be honest to yourself: how often did you forget to remove the @generated tag (or adding a NOT)? Never wondered about strange bugs occuring after re-generation because your previous work was destroyed by an overeager generator? Then you are an outstanding programmer! Regular developers aren't that good.

4. Give me reasons why it should be better to mix hand-crafted and generated code.

/edit: the argumentation with a performance penalty doesn't convince me. The impact of a class hierarchy, which is only 1 level deeper, is pretty low. Furthermore, if you need high performance, you most probably cannot work with generated code anyway. Use-cases for code-generation are not that performance critical. Finally, it is not an argument against providing an option to choose between generation strategies (with / without "generation gap" [I still prefer the term "double-derived"]).

[Updated on: Tue, 11 June 2013 08:38]

Report message to a moderator

Re: Separation of generated code [message #1062882 is a reply to message #1062872] Tue, 11 June 2013 08:58 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Till Fischer wrote on Tue, 11 June 2013 04:06
@Mikael Barbero: Your project seems to be exactly what I was looking for.

I've just found this in the "Limitations" section: "It is not possible to reference a Loophole Generator (.gengapmodel) model from another one. Then it is not possible to create customized Ecore models that reference each others."
Thats too bad! I need cross-references between Ecore models Sad

And as far as I see a generation gap is only supported for Model and Edit code... What about Editor code?
Re: Separation of generated code [message #1062887 is a reply to message #1062872] Tue, 11 June 2013 09:05 Go to previous messageGo to next message
Mikael Barbero is currently offline Mikael BarberoFriend
Messages: 55
Registered: July 2009
Member
Till Fischer wrote on Tue, 11 June 2013 10:06
@Mikael Barbero: didn't know the name for this design pattern. Thanks for this info! Your project seems to be exactly what I was looking for. However I think that such a core feature shouldn't be added side-by-side (additional plugin, yet another genmodel, original genmodel reference), but included in the EMF tooling... any talks with respective persons, yet?


No, not yet, I was waiting for some feedback from users before starting talking about integration.


Best regards,

Mikael Barbero
Obeo
Re: Separation of generated code [message #1062889 is a reply to message #1062882] Tue, 11 June 2013 09:18 Go to previous messageGo to next message
Mikael Barbero is currently offline Mikael BarberoFriend
Messages: 55
Registered: July 2009
Member
Quote:
I've just found this in the "Limitations" section: "It is not possible to reference a Loophole Generator (.gengapmodel) model from another one. Then it is not possible to create customized Ecore models that reference each others."
Thats too bad! I need cross-references between Ecore models Sad


The cross references between Ecore models would need a mechanism to reference loophole models between each other and to provide a runtime registry fo .gengapmodel to let you extend deployed models, (like it is done for genmodel). This would requires a lot of work and I don't have the time to do it.

BTW, it would be easier to support that if .gengapmodel options were integrated into the .genmodel like you said in your previous comment Wink

Quote:
And as far as I see a generation gap is only supported for Model and Edit code... What about Editor code?


The Editor code can't be treated like model and edit code. This is more like a (very complete and usable) scaffolding. The architecture of the editor does not fit into the gen gap pattern that much. Once generated, I've rarely felt the need to re-generate it, even after massive changes to my ecore model.


Best regards,

Mikael Barbero
Obeo
Re: Separation of generated code [message #1062897 is a reply to message #1062889] Tue, 11 June 2013 10:01 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Mikael Barbero wrote on Tue, 11 June 2013 05:18
BTW, it would be easier to support that if .gengapmodel options were integrated into the .genmodel like you said in your previous comment Wink

This should be done first then Wink

Mikael Barbero wrote on Tue, 11 June 2013 05:18
The Editor code can't be treated like model and edit code. This is more like a (very complete and usable) scaffolding. The architecture of the editor does not fit into the gen gap pattern that much. Once generated, I've rarely felt the need to re-generate it, even after massive changes to my ecore model.

I'm just starting to have a closer look at EMF's code generation, but I think I can imagine how this comes off. Sounds good to me. Somewhat off-topic: code generated in the context of GMF is probably less customization-friendly, isn't it? I did not have a very close look at the GMF tooling yet, but my first impression was that it can already be rather cumbersome to keep only ecore and editor model in synch... don't want to think about deeper changes on code-level... thus I doubt I'm going to use GMF...

Back to your tools: too bad that you currently don't have the time to support cross-references in Ecore models; I cannot give you much feedback then. But I can give you some motivation Wink In my opinion it is utterly necessary to provide a mechanism to separate generated and hand-written code. I'm pretty sure that if it was integrated into the .genmodel, a lot of people would use it for new projects.
Re: Separation of generated code [message #1062926 is a reply to message #1062872] Tue, 11 June 2013 12:31 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Quote:
http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html

Sorry Ed, I somehow missed the link to your nice article. I just read it, but the only argument for not having an additional inheritance-level seems to remain the fact, that bloat is added. I still don't believe that the impact is high enough to justify the other disadvantages. But I see that this topic is well-discussed already, thus we don't have to do it again.

@Martin, regarding your link with reasons for pushing generated code to git: I added some comments... Very Happy

    Texo follows the EMF approach (the second school of 
    thought) because:

    it feels more natural to change/add behavior to the 
    generated class than to a 'dummy' subclass.
    
Wrong: the "natural" way of changing/adding behavior of a 
class in OOP is to derive from the class and override / 
add functions. To tamper with foreign code is NOT natural, 
but intrusive and most inconvenient.
    
    less classes are generated and the generated classes 
    are kept in sync with the model.
    
Where is the benefit? Visible for the user is exactly the 
same number of classes. The base class (this one should be 
regarded as the dummy), is not relevant for the developer. 
He never touches it. In the EMF approach generated classes 
are kept in synch with the model with additional effort 
only (tools must PARSE generated classes before 
regeneration!), using the other approach synch is for free.
    
    manual code can easily be identified inside of 
    generated classes.

Wrong: after removing @generated, it is impossible to 
identify the generated "parts" within the function anymore.

    the code generation does not update the file on the 
    file system if it has not changed by code generation. 
    This results in minimal changesets in a CVS, and much 
    better, if something changes it is directly visible in 
    CVS diffs etc.

There shoud be no need for a developer to to care about 
generated code. It is generated, he doesn't write it. It's 
like if you use a library; you don't want to be forced to 
inspect the source code in order to use the library. In 
the CVS tree only changes the own team did are 
interesting; thus only changes in the model or in the 
custom code are relevant.

    by checking in the generated code to cvs it is much 
    easier for others to work with the development project 
    as no generation step is needed after getting the 
    project or updates from a CVS. The same applies to 
    re-distribution of regenerated code, by checking in 
    the generated code (and the changes) it is much 
    clearer what has changed and when people update from 
    the CVS they will receive a consistent state directly.
    
If generated/hand-written code is not mixed but clearly 
separated, the additional step needed after a clean 
checkout (initial generation) is absolutely non-critical 
(good tools would do it automatically in the background, 
the use wouldn't even notice!). Inconsistent states DO NOT 
EXIST, as long as the same generation tools are used. 
Using different generation tools may cause inconsistent 
states using both approaches with same probability.
    
    Texo will re-organize imports and remove files which 
    related to model elements which have been removed. As 
    the code is checked in these removal actions are 
    tracked in a CVS.

Nice that Texo can do this, but it wouldn't be necessary 
if everything wouldn't be jumbled up by EMF ;)

[Updated on: Tue, 11 June 2013 12:31]

Report message to a moderator

Re: Separation of generated code [message #1062965 is a reply to message #1062926] Tue, 11 June 2013 14:33 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Till,
Indeed for sure there are different opinions in the world here :-).
Some reactions. First you can use Mint to see highlighted what you override in the generated class.

Second, it is all about taste. That's why I won't be using the word wrong ;-), I think you are perfectly right and your
arguments make perfect sense, that's also why many people like what you say/argument for. I just have a different
opinion, possibly based on different experiences.

For me, I don't find the extra generated classes really adding much value. Texo generates entities, my experience is
that these entities are not really touched/changed that much. For me it seems more and more logical/better to develop
business logic in separate service classes. For Texo the main purpose for allowing manual changes is to have the
possibility to as-a-last-resort overwrite something specific. So less need for extra classes as they are only for some
corner cases (afaics).

But there is a bugzilla open to support the generation gap pattern also for Texo. As I said, it makes sense, many things
make sense in fact, but it is just what weights you put on different arguments.

gr. Martin

Texo generates mostly entities so no edit or editor code. There is no intention to do that. My experience/o

On 06/11/2013 02:31 PM, Till Fischer wrote:
> Quote:
>> http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
>
> Sorry Ed, I somehow missed the link to your nice article. I just read it, but the only argument for not having an
> additional inheritance-level seems to remain the fact, that bloat is added. I still don't believe that the impact is
> high enough to justify the other disadvantages. But I see that this topic is well-discussed already, thus we don't have
> to do it again.
>
> @Martin, regarding your link with reasons for pushing generated code to git: I added some comments... :d
> Texo follows the EMF approach (the second school of thought) because:
>
> it feels more natural to change/add behavior to the generated class than to a 'dummy' subclass.
> Wrong: the "natural" way of changing/adding behavior of a class in OOP is to derive from the class and override / add
> functions. To tamper with foreign code is NOT natural, but intrusive and most inconvenient.
> less classes are generated and the generated classes are kept in sync with the model.
> Where is the benefit? Visible for the user is exactly the same number of classes. The base class (this one should be
> regarded as the dummy), is not relevant for the developer. He never touches it. In the EMF approach generated classes
> are kept in synch with the model with additional effort only (tools must PARSE generated classes before regeneration!),
> using the other approach synch is for free.
> manual code can easily be identified inside of generated classes.
>
> Wrong: after removing @generated, it is impossible to identify the generated "parts" within the function anymore.
>
> the code generation does not update the file on the file system if it has not changed by code generation. This
> results in minimal changesets in a CVS, and much better, if something changes it is directly visible in CVS diffs
> etc.
>
> There shoud be no need for a developer to to care about generated code. It is generated, he doesn't write it. It's like
> if you use a library; you don't want to be forced to inspect the source code in order to use the library. In the CVS
> tree only changes the own team did are interesting; thus only changes in the model or in the custom code are relevant.
>
> by checking in the generated code to cvs it is much easier for others to work with the development project as
> no generation step is needed after getting the project or updates from a CVS. The same applies to re-distribution
> of regenerated code, by checking in the generated code (and the changes) it is much clearer what has changed and
> when people update from the CVS they will receive a consistent state directly.
> If generated/hand-written code is not mixed but clearly separated, the additional step needed after a clean checkout
> (initial generation) is absolutely non-critical (good tools would do it automatically in the background, the use
> wouldn't even notice!). Inconsistent states DO NOT EXIST, as long as the same generation tools are used. Using different
> generation tools may cause inconsistent states using both approaches with same probability.
> Texo will re-organize imports and remove files which related to model elements which have been removed. As the
> code is checked in these removal actions are tracked in a CVS.
>
> Nice that Texo can do this, but it wouldn't be necessary if everything wouldn't be jumbled up by EMF ;)


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Re: Separation of generated code [message #1062979 is a reply to message #1062965] Tue, 11 June 2013 15:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Martin

Unfortunately Mint is dead. Any rescuers?

Regards

Ed Willink

On 11/06/2013 15:33, Martin Taal wrote:
> Hi Till,
> Indeed for sure there are different opinions in the world here :-).
> Some reactions. First you can use Mint to see highlighted what you
> override in the generated class.
Re: Separation of generated code [message #1062985 is a reply to message #1062965] Tue, 11 June 2013 15:34 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Hi Martin,

I didn't want to be rude when using the word "wrong" Embarrassed And you are right that some things are a matter of taste. But I wonder whether people prefering the current EMF approach ever used evolved tools using the other approach... No offense, but I have the suspicion that it's like with many other things in life: you have arranged with status quo and don't see any reason for something to change. But then the change happens anyway and afterwards you cannot imagine how you could live the other way before Smile

Back to the topic: maybe someone can help me with a concrete but directly related issue: I just realized that if I delete some EClass (MyEClass) from my model and re-generate the code, EMF does not clean up unused imports (=> warnings in the workspace) and even an error emerged in the corresponding MyEClassImpl.java (an unknown reference to MyModel.Package.Literals.MYECLASS; obviously MyModel.Package.Literals is regenerated "correctly" but MyEClassImpl.java not deleted) Confused

Martin, the link you provided in the first post suggests that this problem wouldn't occur using Texo. I expected EMF's genmodel alone would provide similar capabilities. Can I do something to automate such cleanup without leaving the basic EMF environment (I'm afraid that this will happen when using Texo... I'm not 100% sure whether using it is applicable for me, but I don't think so). Please don't tell me that I have to clean up my generated sources every time I rename or delete a model element Confused

Martin Taal wrote on Tue, 11 June 2013 10:33
Hi Till,
Indeed for sure there are different opinions in the world here Smile.
Some reactions. First you can use Mint to see highlighted what you override in the generated class.

Second, it is all about taste. That's why I won't be using the word wrong Wink, I think you are perfectly right and your
arguments make perfect sense, that's also why many people like what you say/argument for. I just have a different
opinion, possibly based on different experiences.

For me, I don't find the extra generated classes really adding much value. Texo generates entities, my experience is
that these entities are not really touched/changed that much. For me it seems more and more logical/better to develop
business logic in separate service classes. For Texo the main purpose for allowing manual changes is to have the
possibility to as-a-last-resort overwrite something specific. So less need for extra classes as they are only for some
corner cases (afaics).

But there is a bugzilla open to support the generation gap pattern also for Texo. As I said, it makes sense, many things
make sense in fact, but it is just what weights you put on different arguments.

gr. Martin

Texo generates mostly entities so no edit or editor code. There is no intention to do that. My experience/o
Re: Separation of generated code [message #1063008 is a reply to message #1062985] Tue, 11 June 2013 18:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Till,

If you use Xcore you can define most (if not all) of what you need
directly in the model, including the bodies of operations, so then you
don't need merging nor a generation gab. By default, it will also
delete files if you delete the EClass from which they originated, at
least for the model. And in the end, even with the generation gap,
you'd still have classes you'd have to delete or rename if you deleted
or renamed your model.


On 11/06/2013 5:34 PM, Till Fischer wrote:
> Hi Martin,
>
> I didn't want to be rude when using the word "wrong" :blush: And you
> are right that some things are a matter of taste. But I wonder whether
> people prefering the current EMF approach ever used evolved tools
> using the other approach... No offense, but I have the suspicion that
> it's like with many other things in life: you have arranged with
> status quo and don't see any reason for something to change. But then
> the change happens anyway and afterwards you cannot imagine how you
> could live the other way before :)
>
> Back to the topic: maybe someone can help me with a concrete but
> directly related issue: I just realized that if I delete some EClass
> (MyEClass) from my model and re-generate the code, EMF does not clean
> up unused imports (=> warnings in the workspace) and even an error
> emerged in the corresponding MyEClassImpl.java (an unknown reference
> to MyModel.Package.Literals.MYECLASS; obviously
> MyModel.Package.Literals is regenerated "correctly" but
> MyEClassImpl.java not deleted) :?
>
> Martin, the link you provided in the first post suggests that this
> problem wouldn't occur using Texo. I expected EMF's genmodel alone
> would provide similar capabilities. Can I do something to automate
> such cleanup without leaving the basic EMF environment (I'm afraid
> that this will happen when using Texo... I'm not 100% sure whether
> using it is applicable for me, but I don't think so). Please don't
> tell me that I have to clean up my generated sources every time I
> rename or delete a model element :?
> Martin Taal wrote on Tue, 11 June 2013 10:33
>> Hi Till,
>> Indeed for sure there are different opinions in the world here :).
>> Some reactions. First you can use Mint to see highlighted what you
>> override in the generated class.
>>
>> Second, it is all about taste. That's why I won't be using the word
>> wrong ;), I think you are perfectly right and your arguments make
>> perfect sense, that's also why many people like what you say/argument
>> for. I just have a different opinion, possibly based on different
>> experiences.
>>
>> For me, I don't find the extra generated classes really adding much
>> value. Texo generates entities, my experience is that these entities
>> are not really touched/changed that much. For me it seems more and
>> more logical/better to develop business logic in separate service
>> classes. For Texo the main purpose for allowing manual changes is to
>> have the possibility to as-a-last-resort overwrite something
>> specific. So less need for extra classes as they are only for some
>> corner cases (afaics).
>>
>> But there is a bugzilla open to support the generation gap pattern
>> also for Texo. As I said, it makes sense, many things make sense in
>> fact, but it is just what weights you put on different arguments.
>>
>> gr. Martin
>>
>> Texo generates mostly entities so no edit or editor code. There is no
>> intention to do that. My experience/o
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Separation of generated code [message #1063077 is a reply to message #1062767] Wed, 12 June 2013 07:38 Go to previous messageGo to next message
Jan Reimann is currently offline Jan ReimannFriend
Messages: 140
Registered: July 2009
Senior Member
You could use EMF Customize from the EMFText guys. It's very cool:
http://www.emftext.org/index.php/EMFText_EMFCustomize

best regards,
Jan

Till Fischer wrote:
> I've already tried the forum search and google but I couldn't find a
> good answer to my question.
>
> I'm wondering whether there are any attempts to provide better
> separation of generated and hand-crafted code using EMF / ecore. IMHO it
> is extremely painful to have one file that contains generated fragments
> interweaved with custom modifications and additions. Especially when
> using SVN or any other versioning system this is none too pleasant :?
> Unfortunately Java does not support partial classes, but it would
> already be a great relief if all generated classes would be
> "double-derived" (a term used by Microsoft in their modeling framework
> VMSDK): every generated class is made up of a base- and a customization
> class. For example, "XXXResourceImpl", which you have to modify to use
> UUIDs for XMI serialization, would be made up of "XXXResourceImplBase"
> and "XXXResourceImpl". Only the first one would contain generated code,
> but only the latter one would be "used" (instantiated/referenced). This
> would allow nearly full customization by overriding corresponding
> methods in "XXXResourceImpl". Even without partial classes this could
> already be enough to get rid of the "@generated" comment ( horrible 8o
> ) completely.
>
> Is someone working on something like this? Or is it available by using a
> magic switch in the genmodel I've not found yet?
>
> I doubt that I'm the first one who asks this, but as I said I couldn't
> find anything...
Re: Separation of generated code [message #1063096 is a reply to message #1063008] Wed, 12 June 2013 09:51 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Ed Merks wrote on Tue, 11 June 2013 14:35
If you use Xcore you can define most (if not all) of what you need
directly in the model, including the bodies of operations, so then you
don't need merging nor a generation gab.

I agree that the concepts behind Xcore are promising. At the current stage of my work it would actually be feasible to switch to a different base technology. But I would have to investigate it in more detail first. Currently I still hope that I can get along with only the very basic EMF tools, because they are established and well-known. Xcore is rather new and with some bad luck I'm using a dead technology in two years.

Ed Merks wrote on Tue, 11 June 2013 14:35
By default, it will also
delete files if you delete the EClass from which they originated, at
least for the model. And in the end, even with the generation gap,
you'd still have classes you'd have to delete or rename if you deleted
or renamed your model.

With the generation gap only those files for deleted/renamed models remain, which were touched by the user hisself (if good implemented: created by the user hisself). Because he already touched them he most likely know them. And because he know them it is easier to handle them manually ("ah, i remember, the crap i did 3am this morning... let's delete it!"). Some generated files, which are unknown to the developer, because he never had to look at them, are different.

I think the problem many experts in this forum have is that they have a different view on the tools than the aimed users have, because they develop the tools. Even if developers also use their tools (and they do!), it is difficult for them to imagine the end-users' perspective. This is because the developer of a code-generator, for example, is very familiar with the code that is generated. He looks at it very often, e.g. when tracing bugs in the generator. This is different for a regular user. To understand the users' perspective, the developer would have to mask some knowlege in his imagination. This is pretty difficult.

I don't think that one might argue that users should know the generated code, because this would correspond to the demand that Java developers need to know details about the underlying bytecode. Some do, but it must not be expected to be the regular case.
Re: Separation of generated code [message #1063203 is a reply to message #1063096] Wed, 12 June 2013 15:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Till,

Comments below.

On 12/06/2013 11:51 AM, Till Fischer wrote:
> Ed Merks wrote on Tue, 11 June 2013 14:35
>> If you use Xcore you can define most (if not all) of what you need
>> directly in the model, including the bodies of operations, so then
>> you don't need merging nor a generation gab.
>
> I agree that the concepts behind Xcore are promising. At the current
> stage of my work it would actually be feasible to switch to a
> different base technology. But I would have to investigate it in more
> detail first. Currently I still hope that I can get along with only
> the very basic EMF tools, because they are established and well-known.
> Xcore is rather new and with some bad luck I'm using a dead technology
> in two years.
:-(
>
> Ed Merks wrote on Tue, 11 June 2013 14:35
>> By default, it will also delete files if you delete the EClass from
>> which they originated, at least for the model. And in the end, even
>> with the generation gap, you'd still have classes you'd have to
>> delete or rename if you deleted or renamed your model.
>
> With the generation gap only those files for deleted/renamed models
> remain, which were touched by the user hisself (if good implemented:
> created by the user hisself). Because he already touched them he most
> likely know them. And because he know them it is easier to handle them
> manually ("ah, i remember, the crap i did 3am this morning... let's
> delete it!"). Some generated files, which are unknown to the
> developer, because he never had to look at them, are different.
That's true.
>
> I think the problem many experts in this forum have is that they have
> a different view on the tools than the aimed users have, because they
> develop the tools.
Well, I also use them extensively. They're not just developed for other
uses, but for personal use as well.
> Even if developers also use their tools (and they do!), it is
> difficult for them to imagine the end-users' perspective. This is
> because the developer of a code-generator, for example, is very
> familiar with the code that is generated. He looks at it very often,
> e.g. when tracing bugs in the generator. This is different for a
> regular user. To understand the users' perspective, the developer
> would have to mask some knowlege in his imagination. This is pretty
> difficult.
Indeed.
>
> I don't think that one might argue that users should know the
> generated code, because this would correspond to the demand that Java
> developers need to know details about the underlying bytecode.
No, but Java developers often need to understand details about the
libraries they use. A user of EMF generating code, really does need to
understand the APIs they're generating at the very least and will
immediately realize that if they have a class Foo in the model, they'll
end up with an interface Foo in the generated API...

> Some do, but it must not be expected to be the regular case.
I don' t think that's a great analogy. Of course I don't need to
understand Java byte code, but when I use tools to generate human
readable source code that I expect to use, and I expect others to use, I
better have some general understanding of the structure and purpose of
that source code.... Of course I don't need to fully understand how
bidirectional references are implemented, but I need to understand how
they behave, and I need to understand the API I'm generating and all the
methods in that API...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Separation of generated code [message #1063503 is a reply to message #1063203] Thu, 13 June 2013 10:27 Go to previous messageGo to next message
Till F. is currently offline Till F.Friend
Messages: 58
Registered: August 2012
Member
Quote:
Sad

I'm sorry that I'm such a conservative thinking person :-/

Quote:
No, but Java developers often need to understand details about the
libraries they use. A user of EMF generating code, really does need to
understand the APIs they're generating at the very least and will
immediately realize that if they have a class Foo in the model, they'll
end up with an interface Foo in the generated API...

This is partially true. The difference is that you only have to understand those parts of an API you actually use. Someone who uses EMF for the first time is not necessarily aware of the concept one-java-class-file-per-ecore-class. Of course he has to understand it soon, if he ever wants to do something useful with EMF, but the order for first-time-users is as follows (IMHO): first modelling and code generation, only then using the API and learning the concepts.

If the only problem that might occur is a "forgotten" .java file it's not such a big issue (already because only the very basic concepts are enough to understand interrelations). But I'm afraid that there might be other generated-only items that are not "cleaned-up" correctly if something is renamed/deleted. I probably wouldn't complain if it wasn't so easy to get rid of such issues once and for all by clear separation of generated and handwritten code (we had this already Wink)...


Quote:
Of course I don't need to fully understand how
bidirectional references are implemented, but I need to understand how
they behave, and I need to understand the API I'm generating and all the
methods in that API...

If the API is good, you only have to know (method) signatures and possibly some behaviour description, but not the methods itself (body/implementaion). But I think this is what you meant as well. However, I don't agree that you have to know *all* methods an API provides. Most commonly only a very small subset is relevant to achieve something particular. The API was bad if you would have to know everything else in order to forbid any unintended behaviour (due to side-effects etc.).

[Updated on: Thu, 13 June 2013 10:34]

Report message to a moderator

Re: Separation of generated code [message #1063644 is a reply to message #1063503] Thu, 13 June 2013 15:04 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Till,

Comments below.

On 13/06/2013 12:27 PM, Till Fischer wrote:
> Quote:
>> :(
>
> I'm sorry that I'm such a conservative thinking person :-/
>
> Quote:
>> No, but Java developers often need to understand details about the
>> libraries they use. A user of EMF generating code, really does need to
>> understand the APIs they're generating at the very least and will
>> immediately realize that if they have a class Foo in the model, they'll
>> end up with an interface Foo in the generated API...
>
> This is partially true. The difference is that you only have to
> understand those parts of an API you actually use. Someone who uses
> EMF for the first time is not necessarily aware of the concept
> one-java-class-file-per-ecore-class. Of course he has to understand it
> soon, if he ever wants to do something useful with EMF, but the order
> is as follows: first modelling and code generation, only then using
> the API.
>
> If the only problem that might occur is a "forgotten" .java file it's
> not such a big issue (already because only the very basic concepts are
> enough to understand interrelations). But I'm afraid that there might
> be other generated-only items that are not "cleaned-up" correctly if
> something is renamed/deleted. I probably wouldn't complain if it
> wasn't so easy to get rid of such issues once and for all by clear
> separation of generated and handwritten code (we had this already ;))...
Xcore, at least for model code generation in default mode (in the
src-gen folder) does this well, i.e., it will delete files that don't
belong anymore. I do plan in the next release to look at how to support
the generation gap approached the Xtext guys are currently using, but my
time is limited.
>
>
> Quote:
>> Of course I don't need to fully understand how
>> bidirectional references are implemented, but I need to understand how
>> they behave, and I need to understand the API I'm generating and all the
>> methods in that API...
>
> If the API is good, you only have to know (method) signatures and
> possibly some behaviour description, but not the methods itself
> (body/implementaion).
Exactly.
> But I think this is what you meant as well.
Indeed.
> However, I don't agree that you have to know *all* methods an API
> provides.
I think you really should know all the methods in the API that's
generated directly from the model. I.e., the interface generated from
your EClass should be exactly as you intend and expect.
> Most commonly only a very small subset is relevant to achieve
> something particular.
Certainly it's not necessary to know all the details of every
class/interface that's generated, but the API for the model you've
defined is the central purpose of your Ecore model and that should be
well understood and each thing in it should serve the purpose you intend
in the definition.
> The API was bad if you would have to know everything else in order to
> forbid any unintended behaviour (due to side-effects etc.).
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Using EMF/GWT with Juno SR1
Next Topic:Consitency Check
Goto Forum:
  


Current Time: Fri Mar 29 16:02:03 GMT 2024

Powered by FUDForum. Page generated in 0.03623 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top