Skip to main content



      Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Re: Accelo
Re: Accelo [message #37124] Sun, 11 June 2006 14:29 Go to next message
Eclipse UserFriend
Hi Sven,

I'm jumping into the discussion just to give my $0.02 if useful at all.

"Sven Efftinge" <sven@efftinge.de> wrote in message
news:e6h2h0$c7k$1@utils.eclipse.org...
> Hi Ed,
>
> Ed Merks schrieb:
>> For example, the fact that JET supports Java syntax can be great if you
>> know Java and don't want to learn yet another language but can be bad if
>> you don't know Java and don't want to learn yet another language.
>
>
> And it is bad, if you try to do a lot of model navigation (which is
> usually the case within generators and transformers). Additionally JET
> relies on Java's type system not on EMF's (Ecore), what I cannot
> understand as you've invented it... (And it's great!)
>

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.

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

>
>>
>> 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 ...
What I see really missing in JET (I don't see it even in JET2) is templates
overriding.
There are ways to do that but they are not so convenient as you need to
define the extension points in the master templates beforehands.

> And, yes, you are right with that it's hard to argue this or that language
> is better or not. But I wanted to direct the attention to what we already
> have before adding another solution for the same problem to the EMP.
>

I fully agree with you on that :)

Cheers,

Joel.
> regards,
> Sven
>
>
>>
>>
>> Sven Efftinge wrote:
>>> I think the main question is: "Why would we need another template
>>> language?"
>>>
>>> We already have three different languages for this purpose:
>>>
>>> JET, MOFScript and Xpand
>>>
>>> JET is indeed not the best template language (only Java type system (not
>>> Ecore), no polymorhic template calls, simple expressions (Java), etc.)
>>> But Xpand and MOFScript are both much better and advanced than anything
>>> I've seen so far (including Acceleo).
>>> In addition Xpand is just one of several languages from the
>>> openArchitectureWare language family. They are all based on the same
>>> type system and on the same OCL expression language.
>>> Maybe we should do a more detailed feature comparism.
>>>
>>> Of course one could use Acceleo (as well as JET, Xpand, MOFScript)
>>> together with the ModelBus. The question is why should I use language X
>>> in favor of language Y, as they all try to solve the same problems. And
>>> the next question is, why should we add another template language to the
>>> eclipse project?
>>> I only can think of one reason (ignoring politics here ;-)):
>>> It is a better language!
>>>
>>> Acceleo isn't.
>>>
>>> regards,
>>> Sven
>>>
>>>
>>> Etienne Juliot schrieb:
>>>> Hi,
>>>>
>>>> From the eclipse modeling project page :
>>>> - Java Emitter Templates (JET) : provides code generation framework &
>>>> facilities that are used by EMF.
>>>> - Model Driven Development integration (MDDi) : produces an extensible
>>>> framework and exemplary tools dedicated to integration of modeling
>>>> tools in Eclipse.
>>>>
>>>> Regarding MDDi, we can imagine the following schema :
>>>>
>>>> ----------------- -----------------
>>>> | external tool | | external tool |
>>>> | ----------- | | ----------- |
>>>> | model based | | text based |
>>>> ----------------- -----------------
>>>> | |
>>>> | |
>>>> QVT Acceleo
>>>> | |
>>>> | |
>>>> -----------------------------------------
>>>> | ModelBus |
>>>> -----------------------------------------
>>>> |
>>>> |
>>>> -----------------------------------------
>>>> | EMF |
>>>> -----------------------------------------
>>>> |
>>>> |
>>>> JET
>>>> |
>>>> |
>>>> -----------------------------------------
>>>> | Eclipse infrastructure |
>>>> -----------------------------------------
>>>>
>>>> So, Acceleo would be used by projects and products which aren't inside
>>>> Eclipse to create generative modules.
>>>> Theses externals tools can be in Java technology, but also in C, Perl,
>>>> PHP, Cobol ...
>>>>
>>>> Basically, developers from these external tools won't be necessary
>>>> familiar with Java or JSP syntax. So it may be difficult for them to
>>>> create adapters for Mddi/eclipse integration.
>>>> Acceleo provides a minimalist syntax : only "if" and "for" are
>>>> provided. So it is quick to catch up with Acceleo and write a small
>>>> Mddi adapter if you are not a JSP or Java expert.
>>>>
>>>> So the idea with Acceleo in Mddi is to ease the creation of glue with
>>>> non model based tools, and enabling non-Java expert to contribute
>>>> easily.
>>>>
>>>>
>>>> S
Re: Accelo [message #37157 is a reply to message #37124] Mon, 12 June 2006 08:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sven.efftinge.de

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)

But there is additional very convenient syntactic sugar like:

//returns a list of all names of all attributes
myEClass.eAllAttributes.name

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

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.


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

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

best regards,
Sven
Re: Accelo [message #37191 is a reply to message #37157] Mon, 12 June 2006 15:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jcheuoua.ilog.com

Hi Sven,

"Sven Efftinge" <sven@efftinge.de> wrote in message
news:e6jnmo$uit$1@utils.eclipse.org...
> 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.
Re: Accelo [message #37225 is a reply to message #37191] Mon, 12 June 2006 16:17 Go to previous messageGo to next message
Eclipse UserFriend
> Yes :) for sure it's cool, and a lot of people will like this. But sti=
ll,
> 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.

> 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 a=
s =

> long as we're in a java wolrd, everything is bing to a java type syste=
m =

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

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

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

> nothing but java, which is not the case for OCL representations and th=
e =

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

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

> Yes, I've tried XPand and I really liked a lot the polymorphism featur=
e, =

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

> 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 w=
as:
I implemented a constraint checker where you could implement the constra=
int
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 :-)

Markus




-- =

Markus V=F6lter

voelter - ingenieurb=FCro f=FCr softwaretechnologie
Ziegel=E4cker 11, 89520 Heidenheim, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org

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
Re: Accelo [message #37293 is a reply to message #37225] Mon, 12 June 2006 20:47 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jcheuoua.ilog.com

Hi Markus

> "Markus Voelter" <schogglad@web.de> wrote in message
> news:op.ta1umwk4474qjy@markust43...
> > 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
Re: Accelo [message #37648 is a reply to message #37191] Fri, 16 June 2006 18:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sven.efftinge.de

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
Re: Accelo [message #37705 is a reply to message #37293] Fri, 16 June 2006 18:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sven.efftinge.de

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
Re: Accelo [message #37736 is a reply to message #37648] Sat, 17 June 2006 14:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jcheuoua.ilog.com

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
Re: Accelo [message #37769 is a reply to message #37705] Sat, 17 June 2006 14:54 Go to previous message
Eclipse UserFriend
Originally posted by: jcheuoua.ilog.com

some more answers :)

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

Agreed. Maybe we should ask ourselves then if people that are making the
generators are the same than people that designs the models/metamodel ? I
bet it's not always true ... and probably mostly the contrary (people
writing the genrators are closer to the PSM than to the PIM).

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

The point is when you're using the generator, you'r in a java world. So it
can be convenient to think of everything as java entities for pragmatic
reason like interoperability etc.

>> Then in the templates you can use
>>
>> MyHelper .selectAllAttributes(myEClass, mew
>> String[]{"name='foo';unsetable=true'"}, ...)
>
>
> You really call this simple, don't you?

I do ... if it isn't for you, you can change the syntax of the methods :)
the logic of the parameters, etc ... that's having control ...

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

Inded .. It's my own little language implemented in java ... this is my
point, yes.

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

No, I mean what you pointed out above there : I can write my own little
language as I want it. I mean I'm not tied to a typesystem M3
implementation, I mean I'm not tied to anything but java in fact.

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

I agree :-) see my other reply : I don't want to say that one should never
use oAW. I tried it, and I understand that this is a very useful tool, and
that people may/will like it (so hopefully I'm trying to have a view a bit
wider). I just argue that you shouldn't say wrong thing about java language
in JET being "limited" or "unpractical".

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

This is true, you're right ... it was'nt a very good example. Velocity
template language is closer to java than to OCL but it's not java ...

>> BTW It's a very enriching discussion. Thanks for sharing all those point
>> of view with us.
>
> I like it, too.

cool :)

Regards
Joel.
Previous Topic:[Announce] EMFT JET 0.7.0 I200606150846 is available
Next Topic:[Announce] EMFT OCL 1.0.0RC5 is available
Goto Forum:
  


Current Time: Wed Jul 16 04:51:39 EDT 2025

Powered by FUDForum. Page generated in 0.11126 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top