[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2t-dev] Backend model as an EMF model
|
Hi Cédric,
I'm not concerned with performance issues. Instead I think the points
you listed are perfectly valid and
I'ld also like to see the backend AST implemented in Ecore. :-)
Btw. I haven't tried the EMF compare component so far, but from what
I've heard it seems to be really cool. Using it in Unittests sounds
very compelling :-)
Regarding serialization: While it seems reasonable to use the Ecore
serialization stuff for serializing the signatures, I think we should
(and I know Arno will ;-)) try to compile the "real" code directly to
Java in order to improve performance. So maybe there should be two
artifacts one for the signatures and one java class for the
implementation.
atb,
Sven
On Mar 31, 2008, at 14:45 , Cédric Brun wrote:
Hi,
One of the discussion we had at EclipseCon, was about having or not
an ecore
based representation of the backend model.
To start this discussion on the mailling list I'll briefly evoke why
I think
this can be interesting, on the other side Sven seemed concerned
with the
computing cost and the "overhead" work of using an Ecore model for
such en
evolving code base.
Please feel free to answer and comment, this mail is just a start
for the
discussion ;)
*Testing*
One of the thing we want to emphasize with the MTL component is code
quality
and test coverage. That mean every step of the generation, from the
parsing
to the evaluation and generation should be covered by unit and non-
regression
tests. Our experience showed that using models, even for
intermediate data
like the backend model, makes it possible to serialize the expected
result of
the MTL2Backend transformation and then compare it with the actual
result
using EMF compare.
*Serialization*
Let's consider the backend model as a "compiled" MTL model. Then
we'll quickly
want to get something similar to the Java .class file. A serialized
backend
model would be this file, and then the EMF URIConverters could also be
leverage to manage inter-model references.
Another assets for this kind of solution is the fact that a
serialized backend
transformation split in many file will only load what is needed to
generate
and not the whole model thanks to EMF's lazy loading.
*References*
At some point we will also need some kind of links between the MTL
model and
the backend one, one obvious use case is the debugger. We'll want to
display
the MTL expressions and functions while evaluating those of the
backend
model. Using EMF it will be easy to create this kind of weaving models
referencing the elements from one to another.
In the same kind of requirements, we'll want to trace the backend2text
transformation to keep traçeability information, then, again, using
an EMF
model makes easy to reference elements from the backend model.
*M2M transformations*
In the first versions the MTL2Backend transformation will, quite
obviously, be
a Java implementation, but some M2M projects provides nice
perspectives in
this domain providing features you don't have in Java, for instance
QVT-Relational can be leveraged to provide incremental
transformation and
then avoid the coast of a huge "one process doing all the stuffs"
transformation.
*Documentation*
Well, it may seem obvious, but having an Ecore model describing all
the
elements a backend model may contain is usefull for people like us ;)
These are just a few examples but the Eclipse modeling world is so
full of
great components that a number of other interesting, or just "fun"
use cases
mixing different tools may arise.
In a nutshell, my concern is that at some point, I have the feeling
we'll want
most of the features of EMF for this model even if it may have a
computing
cost. It seems to me that this overhead will be easier to anhihilate
providing "higher level" optimizations.
Any comment ? Arno, did you had other specific reasons for that
choice (even
If I understand that at some point it can be easier to maintain Java
interfaces than a Ecore model ;)
Cédric
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
--
Sven Efftinge
Phone: +49 431 5606335
Fax : +49 431 5606339
Mobile: +49 175 5274726
web: http://www.itemis.de
blog: http://effi-blog.blogspot.com
team-blog: http://apps.itemis.de/roller/itemislabkiel
mail: sven.efftinge@xxxxxxxxx
xing: https://www.xing.com/profile/Sven_Efftinge
itemis AG
Schauenburgerstraße 116
24118 Kiel
Germany
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael
Neuhaus
