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

["Joel Cheuoua" <jcheuoua@xxxxxxxx>]

Hi Sven,

I'll try to make it short as those threads are becoming heavy,

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

Your example was in reply to the argument "what can be done in OCL/oAW can 
be done in java".
So if it's a question of convenience again, it's not a good argument

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

That's not the point ... please see at the end ...

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

This is precisely my point : you *have to implement* a typesystem for each 
one you want to use ... and how ? using java right ? and probably not as 
simple as you can write a helper class.

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

sorry but "implemented in different ways" is like writing an helper ...

> You cannot implement the Java type system (i.e. reflection API) the way 
> you want...

That's not true ... I gave examples. And again it's the same as 
"implementing the typesystem in different ways" for your specific language.

> 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"))'

Of course if you're choosing the ugliests constructions as an example, it 
won't look convenient.
I'm sure I can find OCL-like constructions that are not so conveninent also, 
and express something more easy with a java helper class.
So again the "convenient" argument doesn't convince me at all ... it's a 
matter of choices and a matter of how you architect it.

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

Don't get you ...

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

? misunderstanding here ... I'm talking about performance using dynamic 
objects not performance using generators. If by saying that a generator 
process takes max 5 sec you suggest you say that we should always generate 
the code, I agree.

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

So intentionally you are wrong when you say JET is tied to the java type 
system.

> You should try other programming languages, there are a lot of really nice 
> concepts out there.

Don't get me wrong : I've tried a lot of new languages ... and I'm still 
using some of them (I'm using OCL ... but not for templates). Some were good 
others were not, but that's not the point ... Again I'm not here to say that 
language A is better than language B. I'm here to say that your argument 
about java being a crap as a language for templates is not valid.

I'm using java for many other parts of my applications, actually for most. 
It's easier for me to know that all this can communicate smoothly, with my 
templates scripting, and that I will not have to switch from a language to 
another each time. And It's somehow indeed also "safer" to know that I can 
use tools like debuggers, IDE etc. to check my java code.

> And btw I really like Java, too, but there is a lot of space for 
> improvement...

Guess what ? I agree :) and the good news is java is still evolving :) I 
just can't understand that because there is a need for improvements people 
are that in a hurry to reinvent other ones to replace it. Languages like OCL 
or QVT for instance are great for modeling purposes. I just don't want them 
to be used for all and everything, and in replacement of what is already 
working for reasons that seems very wrong to me.

>
> best regards,
> Sven