Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Texo/Design Concepts"
(→Change generated code) |
(→Change generated code) |
||
| Line 13: | Line 13: | ||
== Change generated code == | == Change generated code == | ||
| − | There are roughly two schools of thought regarding how to handle and work with generated code. | + | There are roughly two schools of thought regarding how to handle and work with generated code. Both groups consist of experienced, very knowledgeable developers, architects and experts on the field of code generation. |
One school of thought states that generated code should never be changed manually. Generated code should not be committed to a CVS. It should be possible to remove all the generated code, regenerate and then have the same situation as before. In this approach any manual/custom logic should be implemented in subclasses of the generated code. These subclasses can also be generated. This school of thought is what is propagated by developers from the [http://www.eclipse.org/modeling/m2t/?project=xpand|XPand] project. | One school of thought states that generated code should never be changed manually. Generated code should not be committed to a CVS. It should be possible to remove all the generated code, regenerate and then have the same situation as before. In this approach any manual/custom logic should be implemented in subclasses of the generated code. These subclasses can also be generated. This school of thought is what is propagated by developers from the [http://www.eclipse.org/modeling/m2t/?project=xpand|XPand] project. | ||
| Line 19: | Line 19: | ||
The other school of thought states that it should be possible to change generated code. manual changes in the code should remain even if the code is re-generated. Generated code should be checked in to a CVS. This approach is followed by the [http://www.eclipse.org/modeling/emf/|EMF] project. | The other school of thought states that it should be possible to change generated code. manual changes in the code should remain even if the code is re-generated. Generated code should be checked in to a CVS. This approach is followed by the [http://www.eclipse.org/modeling/emf/|EMF] project. | ||
| − | + | Texo follows the EMF school of though because: | |
* it feels more natural to change/add behavior to the generated class than to a subclass. | * it feels more natural to change/add behavior to the generated class than to a subclass. | ||
* manual code can easily be identified inside of generated classes. | * manual code can easily be identified inside of generated classes. | ||
Revision as of 18:58, 30 January 2010
Contents
Introduction
This page gives an overview of the main design ideas which are the basis for the Texo project.
Annotated Models, Annotation generation with manual overrides
Runtime Model
Change generated code
There are roughly two schools of thought regarding how to handle and work with generated code. Both groups consist of experienced, very knowledgeable developers, architects and experts on the field of code generation.
One school of thought states that generated code should never be changed manually. Generated code should not be committed to a CVS. It should be possible to remove all the generated code, regenerate and then have the same situation as before. In this approach any manual/custom logic should be implemented in subclasses of the generated code. These subclasses can also be generated. This school of thought is what is propagated by developers from the [1] project.
The other school of thought states that it should be possible to change generated code. manual changes in the code should remain even if the code is re-generated. Generated code should be checked in to a CVS. This approach is followed by the [2] project.
Texo follows the EMF school of though because:
- it feels more natural to change/add behavior to the generated class than to a subclass.
- manual code can easily be identified inside of generated classes.
- 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.
- 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.
- 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.