[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[m2t-dev] Re: [modeling-pmc] Xpand/Xtend and MTL/QVTO
|
Three interesting topics stand out here that would be great to discuss in a
panel or symposium: language design in the context of MDSD; open source vs.
standards, the ongoing debacle; what is Eclipse and what do you expect from
it? OK, so that last one I've picked up by reading between the lines here
and in other emails that resulted from my initial Xpand OCL email ;)
Anyway, I think QVTO can come to the rescue for many things here (Radek,
brace yourself!). But, as I've already exceeded my quota for the year on
email replies in the last two days (Ed, where are you?), I'll defer to an
in-person discussion. Eclipse Summit Europe or Eclipse World?
Come to think of it, itemis and Obeo need representation on the Planning and
Architecture Councils, no? That would give us all more opportunity to
discuss things in person.
Best,
Rich
On 8/27/08 4:24 AM, "Sven Efftinge" <sven@xxxxxxxxxxx> wrote:
>>
> 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
>>
>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
