Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[m2t-dev] Xpand/Xtend and MTL/QVTO 


Hi,

regarding the differences between MTL and Xpand.
I don't think that OCL is that complicated (maybe the spec lefts too much room for interpretation ;-)). QVTO *is* noisier than Xtend (I could come up with an example if you want to).
IMHO the main difference between Xpand and MTL is that MTL is an implementation of a standard. Good to have it, but we also need something which drives standardization (like EMF does for EMOF). A standard can only evolve if we have made some experiences with new things. So how should we do this if we're all stuck to standards?
OCL is clearly not the holy grail of programming language, from a programming language view point it's rather weak. It has built too much into the language as first class citizen. This is a well known DON'T for langauge designers. Instead trying to find a small set of orthogonal features so that you can built new features as libraries makes a language simpler, more powerful and easier to extend and maintain. The collection types, and higher order functions should be library things not hard wired into the language.
I see another problem with the OMG standards: They separate the different tasks (M2M, M2T, validation) into different languages. Unfortunately we at EMP followed the pattern, so that it is not possible to have a language, where it's possible to mix up code generation and helper methods, model transformation and validation. I know that many people will think "Hey that's good! People who mix up these things are spaghetti programmers". 

I don't think this is true.
Here are some valid scenarios:

*Constraints + helper methods*
Why should I write all helper methods in a separate file, when such a method is only used in one or two constraint in the same file? 

*Templates + helper methods*
The same problem here. MTL + QVTO (also current Xpand + Xtend) forces the user to write helper functions (even the small private ones) into a separate file. Why? 

*Model transformation with concrete syntax method bodies*
Think of a transformation to a Java meta model, where the bodies of methods are just a string (I remember that Rich showed such a transformation at EclipseCon). Than you need to do string concatenation within your model transformation. Templates are a good way to do string concatenation when such bodies get huge. Today it's not directly supported to call a template from a model transformation and it's simple not possible to have the template in the same file or even an inlined template expression. 

*Code generation uses intermediate model transformations*
When generating code I use helper methods to derive values from the input model, things like 

String getQualifiedJavaName(Entity ent) ...

are very common.
I've learned that it's a good thing to have more than just strings as derived values but have more complex information. 
For instance I would like to have something like

JavaClass javaClass(Entity ent) ...

where JavaClass is defined like so:

JavaClass {
    package : String
    name : String
    superClass : JavaClass
    interfaces* : JavaInterface
}

so that in the template I can call

   <<ent.javaClass().superClass().qualifiedName()>>
In this scenario javaClass() is a small model transformation. With Xpand and Xtend it's common to do such things, but we're still forced to put such transformations and helper methods into different files.
To sum it up, I think we need one language with several domain- specific features (for simple M2M, string concatenation (code generation) and validation) In addition we need room for evolution of such languages and corresponding standards, therefore it's good to have both 
 * implementations of standards
 * implementations of our lessons learned
Having both puts us into a good position to further drive those standards and help them becoming really good. 

regards,
Sven

Back to the top