Home » Modeling » M2T (model-to-text transformation) » [acceleo] Extending a module and overriding templates
| [acceleo] Extending a module and overriding templates [message #667127] |
Tue, 26 April 2011 22:06  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm having problems getting inheritance to work. I have a module with a
template that calls two other templates in the same module. I want to
make a second module with overrides for the two called templates, but
the overriding templates in the extending module are not called as
expected. I have tried several variations, based on
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01670.html, but
nothing seems to work.
Here's the code (slightly simplified):
--- generateEDataType1GetSetStrategy.mtl ---
[module
generateEDataType1GetSetStrategy('http://org.eclipse.gmt.emfacade/model/emfacade.ecore')/]
[template public generateEDataType1GetSetStrategy(eClassMapping :
EClassMapping, eFeatureMapping : EFeatureMapping)]
....
{ [generateGetterBody(eFeatureMapping)/]} <-- overridden in other module
....
{ [generateSetterBody(eFeatureMapping)/]} <-- overridden in other module
....
[/template]
[template protected generateGetterBody(eFeatureMapping : EFeatureMapping)]
return t.get[eFeatureMapping.eFeature.name.toUpperFirst()/]();
[/template]
[template protected generateSetterBody(eFeatureMapping : EFeatureMapping)]
t.set[eFeatureMapping.eFeature.name.toUpperFirst()/](e);
[/template]
--- generateEDataType1FieldStrategy ---
[module
generateEDataType1FieldStrategy('http://org.eclipse.gmt.emfacade/model/emfacade.ecore')
extends generateEDataType1GetSetStrategy/]
[template protected generateGetterBody(eFeatureMapping :
EFeatureMapping) overrides generateGetterBody]
return t.[eFeatureMapping.eFeature.name/];
[/template]
[template protected generateSetterBody(eFeatureMapping :
EFeatureMapping) overrides generateSetterBody]
t.[eFeatureMapping.eFeature.name/] = e;
[/template]
[template public generateEDataType1FieldStrategy(eClassMapping :
EClassMapping, eFeatureMapping : EFeatureMapping) overrides
generateEDataType1GetSetStrategy]
[super/]
[/template]
---------------
The main module explicitly calls the generateEDataType1FieldStrategy
template. Single-stepping indicates that the [super/] call works, but
the overridden templates are not called. From the stack frame content, I
don't see any references to any module object, so I'm not sure how it
manages the extends and overrides logic. An explanation would be great!
Hallvard
|
|
|
| Re: [acceleo] Extending a module and overriding templates [message #667165 is a reply to message #667127] |
Wed, 27 April 2011 07:59  |
|
Hi,
The problem is coming from a difference between the overriding system of Java (for example) and the overriding system of Acceleo. In Acceleo, modules are similar to a namespace not a Java object which means that when you are calling "super" you are in the module "generateEDataType1GetSetStrategy" and from this module the fact that there are template overridden by another module is not known. Contrary to an object language where, if you call a method from the superclass, it can dispatch a call to another method to the implementation of the subclass because it overrides the method of the superclass, in Acceleo we only consider overridden method if they are in our scope. Let me give you some examples:
--- Java ---
class A
methodA {}
method B {methodA()}
class B extends A
methodA overrides methodA {}
methodB overrides methodB {super.methodB}
If you are calling methodB on a B object, it will call the implementation of methodB in the superclass and then it will be dispatched back to the subclass B because we are on a B object. Acceleo is not object oriented and therefor the behavior is different:
--- Acceleo ---
module A
templateA
templateB [templateA/]
module B extends A
templateA overrides templateA
templateB overrides templateB [super/]
module C
import module B
If you are calling templateB from the module C, the call to templateB will call the templateB in the module A but the keywords "extends" is just a modifier for the visibility of the module elements of the module A in relation to the module B it does not really create a relation between a "module A" and a "module B", those are not objects there are "just" namespaces. You could consider that the "extends" keyword should be used to give a namespace the content of public and protected elements from another namespace.
--- Acceleo ---
module A
templateA
templateB
module B extends A
templateA overrides templateA
templateC
module C
imports B
Thanks to the "extends" keyword on module B, you can call three templates from the moduleC:
- templateC from the module B
- template A from the module B
- template B from the module A
With your organization, you can copy the behavior of "generateEDataType1GetSetStrategy" in "generateEDataType1FieldStrategy" or you should maybe consider another organization for your templates.
It is subtle to understand because "extends" and "overrides" feel like object oriented programming but it is not. Modules are namespaces, not objects, they are here to organize your operations (template/query), you never manipulate a module.
I will update the F.A.Q in order to detail everything about overriding in Acceleo (included the dynamic overriding).
Stephane Begaudeau, Obeo
--
Twitter: @sbegaudeau
Acceleo wiki: http://wiki.eclipse.org/Acceleo
Blogs: http://stephanebegaudeau.tumblr.com & http://sbegaudeau.tumblr.com
[Updated on: Wed, 27 April 2011 08:30] Report message to a moderator |
|
|
| Re: [acceleo] Extending a module and overriding templates [message #667171 is a reply to message #667165] |
Wed, 27 April 2011 08:29 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Stephane,
Thanks for the explanation!
I did some experimentation yesterday evening and night and came to the
same conclusion: That the "super"-module cannot call back into the
"sub"-module, as if a module corresponded to a class and the templates
to methods in an object-oriented system.
My design works if I
1) import the "sub"-module in the "super"-module, since then the
overriding templates are within scope and
2) introduce a parameter that control which template is selected, based
on super/sub-type relations.
So, the extends/overrides technique works for modularization purposes,
but it is a bit counter-intuitive to someone used to Java and requires
that a "super"-module "knows" about the relevant "sub"-modules and their
overriding templates.
I can live with it, now that I understand it! But I still wonder about
the design rationale, doesn't the O in OMG stand for "Object" ;-)
Hallvard
On 27.04.11 09.59, Stephane Begaudeau wrote:
> Hi,
>
> The problem is coming from a difference between the overriding system of
> Java (for example) and the overriding system of Acceleo. In Acceleo,
> modules are similar to a namespace not a Java object which means that
> when you are calling "super" you are in the module
> "generateEDataType1GetSetStrategy" and from this module the fact that
> there are template overridden by another module is not known. Contrary
> to an object language where, if you call a method from the superclass,
> it can dispatch a call to another method to the implementation of the
> subclass because it overrides the method of the superclass, in Acceleo
> we only consider overridden method if they are in our scope. Let me give
> you some examples:
>
> --- Java ---
> class A
> methodA {}
> method B {methodA()}
>
> class B extends A
> methodA overrides methodA {}
> methodB overrides methodB {super.methodB}
>
> If you are calling methodB on a B object, it will call the
> implementation of methodB in the superclass and then it will be
> dispatched back to the subclass B because we are on a B object. Acceleo
> is not object oriented and therefor the behavior is different:
>
> --- Acceleo ---
> module A
> templateA
> templateB [templateA/]
>
> module B extends A
> templateA overrides templateA
> templateB overrides templateB [super/]
>
> module C
> import module B
>
> If you are calling templateB from the module C, the call to templateB
> will call the templateB in the module A but the keywords "extends" is
> just a modifier for the visibility of the module elements of the module
> A in relation to the module B it does not really create a relation
> between a "module A" and a "module B", those are not objects there are
> "just" namespaces. You could consider that the "extends" keyword should
> be used to give a namespace the content of public and protected elements
> from another namespace.
>
> --- Acceleo ---
> module A
> templateA
> templateB
>
> module B extends A
> templateA overrides templateA
> templateC
>
> module C
> imports B
>
> Thanks to the "extends" keyword on module B, you can call three templates:
> - templateC from the module B
> - template A from the module B
> - template B from the module A
>
> With your organization, you can copy the behavior of
> "generateEDataType1GetSetStrategy" in "generateEDataType1FieldStrategy"
> or you should maybe consider another organization for your templates.
>
> It is subtle to understand because "extends" and "overrides" feel like
> object oriented programming but it is not. Modules are namespaces, not
> objects, they are here to organize your operations (template/query), you
> never manipulate a module.
>
> Stephane Begaudeau, Obeo
> --
> Twitter: http://twitter.com/#!/sbegaudeau
> Acceleo wiki: http://wiki.eclipse.org/Acceleo
> Blogs: http://stephanebegaudeau.tumblr.com & http://sbegaudeau.tumblr.com/
>
|
|
| |
| Re: [acceleo] Extending a module and overriding templates [message #784647 is a reply to message #667182] |
Fri, 27 January 2012 20:34 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Stephane
The MOFM2T is hardly explicit, but just before Clause 7.1:
"Overriding is a mechanism to selectively modify the behavior of a Module. An overriding template should have the same number of parameters as the overridden template with compatible types. The overriding template is invoked in place of the overridden template when the parameter types match and the guard condition of the former evaluates to true."
says nothing about modules and namespaces, just types, so IMHO the specification is OOP. If types and guard match, the modified behavior applies.
Regards
Ed Willink
Stephane Begaudeau wrote on Wed, 27 April 2011 05:03Hi,
I have updated the FAQ with explanation on overriding: click me !
But I still wonder about the design rationale, doesn't the O in OMG stand for "Object" ;-)
The OMG has defined non-object oriented specifications in the past like the functional language OCL. But yes, MOFM2T feels sometimes like OOP but it's not really OOP :)
Stephane Begaudeau, Obeo
--
Twitter: @sbegaudeau
Acceleo wiki: http://wiki.eclipse.org/Acceleo
Blogs: http://stephanebegaudeau.tumblr.com & http://sbegaudeau.tumblr.com
|
|
|
Goto Forum:
Current Time: Thu Apr 25 10:46:41 GMT 2024
Powered by FUDForum. Page generated in 0.03103 seconds |
] 
Search
Help
Register
Login
Home
