[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[m2t-dev] RE: [modeling-pmc] Xpand/Xtend and MTL/QVTO
|
Tried hard not to jump into discussion, thirst for knowledge kills me ;)
> *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?
What's the problem with few OCL's context, def and inv in the same file? (def: for helpers, inv: for constraints)?
> *Model transformation with concrete syntax method bodies*
Just curious, how you gonna handle FILE statement withing these templates?
> *Code generation uses intermediate model transformations*
> When generating code I use helper methods to derive values
> from the input model, things like
It's already in QVT, no need to invent a thing ;)
Best wishes,
Artem Tikhomirov
> -----Original Message-----
> From: modeling-pmc-bounces@xxxxxxxxxxx
> [mailto:modeling-pmc-bounces@xxxxxxxxxxx] On Behalf Of Sven Efftinge
> Sent: Wednesday, August 27, 2008 10:25 AM
> To: Model to Text
> Cc: PMC members mailing list
> Subject: [modeling-pmc] 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
> >
>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
>
