[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[News.eclipse.technology.mddi] Re: Accelo 
Hi Joel,

see my comments below...

Joel Cheuoua wrote: 
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 ?

I wanted to show that expressions on models are very inconvenient in Java compared to languages supporting higher-order functions.


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. 

Why? Because, you don't trust any other language than Java?


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

OAW's typesystem can be implemented in order to be mapped to different meta-meta-models. As I said before, we have implementations for Ecore, UML2 (incl. profiles) and JavaBeans. We could simply add implementations for MDR, DOM, etc.

Each implementation uses the reflection layer provided by the underlying platform. For instance, the JavaBean impl uses Java reflection and the Ecore impl uses the EObject reflection API.


... 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 an interpreted language you are tied only to the typesystem of the respective language, which can be implemented in different ways (as I explain above).
You cannot implement the Java type system (i.e. reflection API) the way you want...



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.


I'm not talking about *if* we can do it but *how* we do it.
It is perfectly clear to me, that everything (and much more) you can do with OCL you can do with Java.
It's just that 'this.name' looks much more convenient and readable to me than 'obj.eGet(obj.eClass().getEAttribute("name"))'


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 :


Would be very unpleasant if not, as you are using Java (JET) to access it ;-)


It's not very scalable to work with dynamic model elements with their properties stored in hashmaps ...


Could we please omit the 'performance argument'?
For me it has always been more than scalable enough. (A usual generator process takes max 5 sec.)



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 ? 


Yes, intentionally I don't consider using reflection.


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.


You should try other programming languages, there are a lot of really nice concepts out there.
And btw I really like Java, too, but there is a lot of space for improvement...

best regards,
Sven