[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [m2t-dev] RE: [modeling-pmc] Xpand/Xtend and MTL/QVTO
|
We are getting far from 'getting the knowledge" and instead shifting to a general discussion ;) You outlined few things that seems limiting to you, my perception was that these functionalities are already present, hence I asked the questions, and instead we end up with a religious flame "standards are (not) good" ;)
1. *Constraints + helper methods*. I thought this is possible, while you outlined this as a limitation of present approaches. Hence, I asked what's wrong with the approach that to me looks like an answer.
2. Next one was sort of trying to backup FILE removal from GMF-Xpand ;) As we already use it in a way "gimme a string", we faced the issue with side-effects statements, and to me, appropriate solution is not to allow any such operation (at least, do not advertise it at a language level, as a side note, that's MTL problem as well). ">>How about a compiler check?" - How'd xpt compiler find out that DEFINE being compiled would be invoked from a M2M transformation? Hence, I don't see a place for compiler check (other than project-wide setting)
3. Third point of interest was "*Code generation uses intermediate model transformations*", which is nothing new to me, again, as (1) above, and I was wondering if it's not what you were looking for.
> > Again: Why do people invent frameworks like GMF? Isn't it
> possible to build graphical editors without it?
I can name counterpart for Xpand's expression language - OCL, and can name counterpart for Xtend - OCL/QVT.
Could you name a component that does pretty much the same GMF does? I bet not. Building graphical editors with handcrafting java code and using GMF *is different*, while writing expressions in OCL is no different from writing expressions with Xpand's counterpart language. That's what "new" is all about ;)
> > But than I really wonder why you don't use and contribute
> to MTL, as it's OMG's answer to M2T.
We'll surely consider MTL once it's released. And we'll gladly use once it meets our scenarios. So far, I see few design issues with it, besides, I'm 100% sure implementing it will surface a lot of problems with the spec itself, let alone runtime setup issues. Since GMF is on a 'practical' path - we can't afford "research on a topic of language design", it's not our realm ;), we stick to solutions that work today. At the same time, these "solutions that work" should rather be "proven solutions" than "testbed of language design" ;)
Best wishes,
Artem Tikhomirov
> -----Original Message-----
> From: m2t-dev-bounces@xxxxxxxxxxx
> [mailto:m2t-dev-bounces@xxxxxxxxxxx] On Behalf Of Sven Efftinge
> Sent: Wednesday, August 27, 2008 5:33 PM
> To: Model to Text
> Subject: Re: [m2t-dev] RE: [modeling-pmc] Xpand/Xtend and MTL/QVTO
>
>
> > 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
>
>
