Re: [m2t-dev] Backend model as an EMF model

[Arno Haase <arno.haase@xxxxxxxxxxxxxxxxxxxx>]

Hi,

you have me convinced - the backend will be based on an ecore model. I 
have given it some thought, and while I did not see benefit initially, I 
see it now and will refactor it accordingly in the near future.

I will keep you updated. Thanks for the feedback and suggestion!

- Arno

Sven Efftinge schrieb:
> 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

--
Arno Haase
Langemarckstr. 16
53227 Bonn

Mobil: +49 160 98525085
Tel:   +49 228 9654443
Fax:   +49 228 9654448

Attachment: signature.asc
Description: OpenPGP digital signature