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

["Joel Cheuoua" <jcheuoua@xxxxxxxx>]

Hi Sven,

"Sven Efftinge" <sven@xxxxxxxxxxx> wrote in message 
news:e6jnmo$uit$1@xxxxxxxxxxxxxxxxxxxx
> 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)

Hmmm ... sorry I may have missed what you want mean here. My understanding 
is that you just show in your example that what can be done in your oAW can 
be done in java ... am I wrong ?

>
> But there is additional very convenient syntactic sugar like:
>
> //returns a list of all names of all attributes
> myEClass.eAllAttributes.name

Yes :) for sure it's cool, and a lot of people will like this. But still, 
again I'd rather code my own java helper classes and call them in my 
templates. Of course if it were not possible to write the helper, I'd go for 
a syntax like this one.

>
>>
>> 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).
>

Sorry I may be stubborn or really stupid but I still don't get it when you 
say JET is bind to the java type system ... of course he is, but as long as 
we're in a java wolrd, everything is bing to a java type system isnt't it ?
You said that with a language like OCL, anything could work as long as it's 
a java object ... well I don't see why it won't be true for JET ...
In addition, your OCL-like language should work on top of a specific 
meta-meta-model (aka M3 model for OMG 'Ms' lovers) right ? I mean to be able 
to interpret "myEClass.eAllAttributes.name" you must have an engine that 
knows that he should search the feature named "eStructuralFeature" in the 
"Eclass" meta-meta-model, then look at the features of this 
"eStructuralFeature" feature and finds "name", etc. So you are tied to ECore 
... not that it's bad at all, it's good ! :) but as you mention that JET is 
restricted to the java type system, I can argue that in JET you're tied to 
nothing but java, which is not the case for OCL representations and the like 
that are tied both to java *and* to a specific M3 model (at least at 
runtime).

> 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.
>

Why do you say we need to generate the classes ? if the object is an dynamic 
EObject, you can access to any property/reference with the reflection API. 
Even if you're using another "dynamic" meta-model representation, you'll 
still have some java HashMap & al. structures to access the meta data ... so 
you can use java API to get them. Again it's not always convenient indeed, 
but it's doable. If it's not a dynamic EObject but a generated one, it's is 
even simpler and besides, most of the input I use are realized in java : 
It's not very scalable to work with dynamic model elements with their 
properties stored in hashmaps ...

>
>  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...
>

Hmmm ... a dialog of the deaf ? :) or maybe it's just that you didn't 
consider accessing the metadata through reflective mechanisms and API 
instead of standard java accessors like methods or attributes ?

>>
>>>> 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?


No, I'll just bring my contribution to building UI tools on top of it.
Of course like everyone here I may express some request for JET2, but I'm 
not part of the team that is designing it.

> 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.
>

Yes, I've tried XPand and I really liked a lot the polymorphism feature, and 
the AOP thing also, altough I'm still skeptical about managing aspects on 
very large files.

Please understand that I don't want to argue about which language is better 
than which other. Like Ed and you said it's difficult to say. I'm a JET 
adept mainly because I'm an EMF fan and I used to work with JET since a 
while, and so far I didn't saw a lot that could've make my day better. But 
again this is because I'm mainly a java coder, and a bit lazy to decide that 
I should learn another OCL-like syntax for my scripting needs.

> best regards,
> Sven

Kindest regards,
Joel.