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

["Joel Cheuoua" <jcheuoua@xxxxxxxx>]

Hi Markus

> "Markus Voelter" <schogglad@xxxxxx> wrote in message 
> news:op.ta1umwk4474qjy@xxxxxxxxxxxx
> > 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.
>
> in our view, it's the other way round. As long as you can write your
> the helper in the expression language (using one or two lines of code)
> I'll do it in the expression language. Only when (and that is very rare,
> based on our experience) you can't do that, you'll implement an escape
> into Java.

I understand your view ... again I'm not saying it is not a valid or not a 
cool one.
I'm just sharing what are my preferences/habits on that topic to stress out 
the fact that your view is not the only valid view we have.

> > 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 ?
>
> The point is that we're first and foremost in the modelling world!
> And there, the model's type system (aka the metamodel and the meta meta
> model) is relevant. The (potential) mapping to Java code is not the
> most important point here.

This argument seems very wrong to me ... just because we're in "the modeling 
world" does'nt mean we don't care about other technologies ... this is just 
a way to shoot a bullet in our own foot ... failures of 80's CASE tools were 
partly due to this sectary point of view. Let's try to be pragmatic here.

> > You said that with a language like OCL, anything could work as long as 
> > it's a java object ...
>
> actually, anything works as long as you've got an interpreter for the
> meta-metamodel underlying it.
>

Hmmm ... at the end of the day, when you want to make it work, which kind of 
input are you giving to the interpreter ? how is it implemented ? in working 
software, runtime is also very important if not more important, and being 
pragmatic is also not forgetting this.

> > well I don't see why it won't be true for JET ...
>
> because JET works on Java code. There's not way to interpret other
> data structures unless you create a Java-class based representation
> for them.
>

Again this is not true ... you can use reflection.

> > 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).
>
> oAW's expressions are not tied to Java (unless you count the fact that
> the interpreter is implemented in Java!), but only to the M3.
>
> > 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.
>
> wow, yes, you could, but that would result in really long-winded syntax.
> You don't want to do this in everyday development!

I partly agree ... What is doing the OCL interpreter else than using a 
reflection API but in a much more sophisticated way ?
Here the point is simply to write yourself simple parts of this interpreter 
and capture them to a helper at your will ...

Like this :

class MyHelper {
    public static List selectAllAttributes(EClass myEClass, String[] params, 
int options) {
        <implement your stuff there>
    }
}

Then in the templates you can use

MyHelper .selectAllAttributes(myEClass, mew 
String[]{"name='foo';unsetable=true'"}, ...)

just as you were using your own language ... but it's java.
The main difference is in one case there is an non-negligeable entry cost, 
but you have the control on the "interpreter" in the other case you have 
less control, but its easier.

I repeat it because maybe you misunderstand what I want to say with this 
whole stuff : It is that some like to have it their way :) as simple as that 
... it's a matter of preferences, and either choice aren't better than the 
other.

>
> > 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.
>
> things that aren't convenient, won't be done in practice (at least my
> customers won't do it then :-))
>

I can understand that, and of course I somehow agree ... though conveniences 
are multidimensional and it's still a questions of choices at the end : for 
me (and I speak as a user, a "consumer" of code generation technologies) I 
had to choose between conveniences that brings OCL-like syntaxes over 
convenience to be able to control the scripting in my favorite language. I 
choosed the latter. Of course the best of both world would be great.

> > 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.
>
> true, but managing families of generators without aspects is even worse,
> we learned that the hard way in a number of projects, primarily in the
> embedded domain.
>

I trust you :) you certainly have much more experience on that than I do.

> > 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.
>
> actually, I can understand that. When Sven told me about the expression 
> language
> (at that time, mainly used for costraint checks) the first thing I did 
> was:
> I implemented a constraint checker where you could implement the 
> constraint
> checks in Java because
> * I wasn't sure the expression language would handle all my use cases
> * and I didn't want to learn the language.
>
> And guess what: I never ever used my own component, because after about
> an hour of playing around with the OCL expressions, I was convinced. One
> line of code instead of two nested for's for checking name uniqueness
> convinced me :-)
>

Gosh ... you've been taken by the dark side ;-) lol
Ok, I quite understand, and I guess I just did'nt make this step.
I'd say that maybe I would've done it if I was really forced to use XPand, 
but as I'm not, I'll rather stick on JET, Velocity, JSP and the like :)

BTW It's a very enriching discussion. Thanks for sharing all those point of 
view with us.

Cheers,

Joel.

> Markus




-- 
Markus Völter

voelter - ingenieurbüro für softwaretechnologie
Ziegeläcker 11, 89520 Heidenheim, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@xxxxxxx

Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net

PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg