Re: [m2t-dev] RE: [modeling-pmc] Xpand/Xtend and MTL/QVTO

[Cédric Brun <cedric.brun@xxxxxxx>]

Artem (and the GMF team),

You might not be aware that since the MTL relaunch plan 
(http://wiki.eclipse.org/M2T/MTL_Relaunch_Plan) a lot of progress has been 
made and you can even have a try our consumable build bits (
http://www.eclipse.org/modeling/m2t/downloads/?project=mtl )

MTL is very similar to what an OCL/QVTO based Xpand looks like (lets just 
ignore  the separator ;) ) and it's meant to integrate with the others OMG 
standards. (http://www.omg.org/spec/MOFM2T/1.0/)

Understand me, I'm not telling you can pick MTL and put it in GMF as is, 
though the engine will get ready during this fall and the Galileo release will 
bring all the nice user interface and tooling. 

We migh even work together to clearly define the specific feature you would need 
and plan then in the component roadmap. Let's do this early so that our design 
choices are compatible with your needs. 

Have a look on what's already been done, you might be surprised.

Cédric Brun



Le Wednesday 27 August 2008 17:33:07 Sven Efftinge, vous avez écrit :
> > Artem,
> >
> >> The point I was trying to make was you don't need "yet another
> >> language" to try new things, as you'll duplicate what's already
> >> done anyway (e.g. all base expression stuff, QVTO ModelTypes, etc).
> >
> > So why do people invent new programming languages when there's let's
> > say 'Java'? Won't they just duplicate all base expressions and many
> > other concepts?
> > It's not possible to remove or change concepts from standards
> > without loosing compatibility. Unfortunately this is necessary in
> > order to evolve.
> >
> >>>>> *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)?
> >>>
> >>> It's that there are defs in OCL and queries in QVT.
> >>> How do they differ?
> >>
> >> Original question was about constraints and helper methods in the
> >> same file. To me, single OCL file with constraints (inf) and
> >> helpers (def) is possible and hence, solve the issue - nothing to
> >> invent here.
> >
> > Again: Why do people invent frameworks like GMF? Isn't it possible
> > to build graphical editors without it? problem solved - nothing to
> > invent.
> >
> >>>>> *Model transformation with concrete syntax method bodies*
> >>>>
> >>>> Just curious, how you gonna handle FILE statement withing these
> >>>> templates?
> >>>
> >>> I don't need a FILE statement therein, because such strings go into
> >>> the model being transformed not in a file.
> >>> Or do you mean conceptually from a language designer view point?
> >>
> >> I mean, how would you forbid clients from using FILE statement from
> >> their templates you intend to invoke from a transformation?
> >
> > How about a compiler check?
> >
> >>>>> *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 ;)
> >>>
> >>> What is in QVT? Code generation capabilities?
> >>> I want to be able to define templates and model
> >>> transformations in the
> >>> same file.
> >>
> >> The usecase you described was intermediate model (JavaClass),
> >> that's the thing already done in QVT. Given one can invoke QVT
> >> operations from Xpand - consider problem solved. Not from a single
> >> file, though, but as you mentioned, it's "spaghetti" code, and
> >> rarely percieved as good code.
> >
> > It's not spaghetti code generally! That's what I was trying to say.
> >
> >> Again, the point I'm trying to make is that one don't need to have
> >> all the basic stuff done himeself just to research on new
> >>
> >> approaches. I'm arguing statement you made:
> >>> 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?
> >>
> >> First, it turns out a lot of things are already possible with
> >> "standards", just need to get using them, rather than ignoring them.
> >
> > I don't ignore them, would I otherwise be aware of their
> > limitations? (I'm also aware of some good things in it, but it seems
> > that I don't have to elaborate on this here ;-))
> >
> >> Second, nothing prevents you from imporving a standard, trying new
> >> things on top of it.
> >
> > The specification prevents me from doing so.
> > One really good thing about standards is that different
> > implementations are compatible with each other.
> > It's really hard to stay compatible and improving a language at the
> > same time.
> >
> > All in all it sounds like you're not really interested in going
> > beyond the OMG standards, and that's perfectly ok.
> > But than I really wonder why you don't use and contribute to MTL, as
> > it's OMG's answer to M2T.
> >
> > atb,
> > Sven
>
> _______________________________________________
> m2t-dev mailing list
> m2t-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2t-dev