[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[News.eclipse.technology.mddi] Re: Accelo 
some more comments... :-)

Joel Cheuoua schrieb: 
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.

I think you missunderstood markus, here.
He wanted to say, that as we are working on models and metamodels the whole day long when we are developing generators, we want to have the best tools possible.

We don't want to do everything using the swiss knife.
For instance, if I'm felling trees the whole day a chainsaw might work better. That is what pragmatism means to me.



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. 

I don't understand the point, here...


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'"}, ...) 


You really call this simple, don't you?



just as you were using your own language ... but it's java. 


"name='foo';unsetable=true'" is not Java,
it's your own little language.


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. 

What do you mean by control? Don't you mean trust?



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.

But maybe one or both of use can learn something new, and therefore adjust his view a bit ;-) Pragmatism is also about learning new things and wider our horizon, isn't 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. 
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, it would be great to see features like extensions, closures and type inference in Java like they are included in C#3.0

But I live (and work) now :-)


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.: Velocity isn't Java...


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

I like it, too.

regards,
Sven