[
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
|
It was my intend to have a general discussion about why it's important
to have implementations of standards and implementations which are not
bound to standards.
I don't understand why you call such a discussion a religious flame.
We need to know why we're doing the things we're doing, right?
Sven
On Aug 27, 2008, at 6:58 PM, Artem Tikhomirov wrote:
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
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
