[News.eclipse.technology.mddi] Re: Accelo

[Sven Efftinge <sven@xxxxxxxxxxx>]

Hi Joel,

Joel Cheuoua schrieb:
> I think you're making exactly Ed's point here : you can perfectely navigate 
> in the model ... using java. And yes Ecore is great ;) but I don't see why 
> accessing it with its java implementation is very different than accessing 
> it with yet another language. Wetter you're using java, ocl or any other 
> language, navigating on Ecore is relying on Ecore.

The following example should illustrate what I mean:

// a query to all settable attributes
// oAW expression :

myEClass.eAllAttributes.select(attr|!attr.unsettable)

// Java:

List attributes = myEClass.getEAllAttributes();
List result = new ArrayList();
for (Iterator iter = attributes.iterator(); iter.hasNext();) {
   EAttribute attr = (EAttribute) iter.next();
   if (!attr.isUnsettable())
      result.add(attr);
}
return result;

(in short: Java lacks closures)

But there is additional very convenient syntactic sugar like:

//returns a list of all names of all attributes
myEClass.eAllAttributes.name

> For java lovers (like me :)) this is just perfect. I don't want to use any 
> other ocl-like langage for that. OCL is fine, but I prefer java. Besides, 
> this makes JET templates ready for accepting just any java realized meta 
> data schemes, not only Ecore.

No, this binds JET directly to the Java typesystem.
In contrast if you would add an abstraction layer (e.g. an interpreted 
language like OCL) you are *really* ready for everything (as long it's a 
java object).

With oAW, for example, it's 100% transparent if the underlying model is 
dynamic EMF or instances of the generated Java classes. Another example: 
We have an implementation of the abstraction layer for UML2 profiles.
Stereotypes are dynamically mapped to types and tagged values are mapped 
to attributes.
Or imagine a schema implementation which dynamically maps a DOM to the 
types described in the schema.

You cannot do such things with Java as long as you don't generate the 
corresponding classes.


 Science-fiction example : If you decide to
> have a complete EMOF metamodel implementation that is reflective and 
> realized in java (another hot issue isn't it ? ;) ) or Realistic example : 
> even simply plain java objects, with metadata stored into hashmaps or 
> accessible through java 5 annotations ... then you can still use JET 
> templates for the code generation.

And you will always be bound to the Java type system instead of really 
using (and integrating) the available metadata...

> > > Note that the JET2 work introduces a lot of capabilities not in JET, such 
> > > as taglib support:
> > >
> > >     http://www.eclipse.org/emft/projects/jet/
> >
> > Yes, I've seen it and there are definitely some promising ideas in JET2, 
> > but I really miss integration of EMFT's OCL expressions (or something 
> > similar) and therefore support for dynamic EMF models.
> > But we already talked about this in the EMF newsgroup (thread "Template 
> > Language")
>
> Indeed, this is again OCL vs. Java. And I can perfectly understand why you 
> miss this OCL integration. I just wanted to point out the fact that as Ed 
> said, some prefer java some else don't, and I'm one of the people that 
> prefer java ...

Okay, I hope I've made my point clear.


> What I see really missing in JET (I don't see it even in JET2) is templates 
> overriding.


Are you taking part in the design process of JET2?
If yes, have you had a look at the different concepts provided by Xpand 
or MOFScript? Allthough it's a different approach, maybe you could grap 
some features you like.
Xpand offers template overriding with polymorphism (on all parameters)
additionally you can overwrite templates from outside using the AOP feature.

best regards,
Sven