[news.eclipse.technology.ldt] Re: Beyond textual represenations...

[Constantie Plotnikov <constantine.plotnikov@xxxxxxxxx>]

Guillaume Pothier wrote:
> > I'm a bit puzzled why do you use term "AST". "AST" assumes that there 
> > is a syntax to parse and that there may be a concrete syntax tree. I 
> > suggest to use the word "model". This naturally moves this discussion 
> > to EMF group and GMF group. EMF is already a ready "AST framework" and 
> > solves problem for non-textual representations.
>
> You are right, "model" is much more representative of what I am thinking 
> of than AST, which is more restrictive.
> Regarding EMF, here is my understanding of the framework, correct me if 
> I'm wrong:
> - it provides a structural model of OO apps quite similar to UML, 
> hardcoding the notion of class, method, inheritance, etc.

I do not understand. EMF is meta-language. You could define own 
languages using it. It is possible to define UML model with it. It is 
also possible to define other models with it. For example in one of the 
project it was used to model energy consumption schedule. See MDA papers 
at http://www.omg.org/mda/ to understand context of the project better.

> - it generates Java (only) source code for this structural model
There is a generator that generates Java code. I see no problem with it 
in the context of LDT project. As I understand the implementation 
langauge is Java.

You could generate code to any programming language. Possibly it will be 
required to add generator specific annotations. I actually plan write a 
generator for .NET during next stage of one of my research projects.

I once finished planning stage for C++ code generator. But I have not 
needed it because I was able to squeeze required perfromance levels from 
pure-Java code.

Note that EMF is losely based on OMG MOF. And AFAIR there were code 
generators for MOF that generated C, C++ and Java code.

> - it cannot represent application logic (ie. method bodies) except for 
> the structural aspects defined in the model (getters, setters...)

Currently method implementation have to be written in Java.

As I understand there are efforts to implement support of OCL for EMF 
models (see for example http://www.zurich.ibm.com/~wah/doc/emf-ocl/).

So this restriction might be overcome if someone will acutually bother 
doing it.

> Overall, I don't think it is a good fit for LDT, at least in its current 
> form. It looks more like a framework for authoring structural models of 
>  Java applications, than a framework that enables authoring of language 
> models and their implementations (ie. tooling, inculding compiler, 
> editors etc), which is what I feel LDT should be...

As I said emf might be used to create any models: uml, emf (yes it is 
expressed in itself), Gantt charts, stock portfolios in banking 
applications, energy consumption schedule, bibliography metadata, css, 
and ll1-grammars. And that is just what I personally witnessed my 
applications or in applications developed by others.

> However, I don't doubt that they have a good infrastructure for 
> persisting and managing their models, and the creation of the GMF 
> project is exciting. But they both seem tied to Java or Java-like 
> languages, and at least to OOP...
> I feel that LDT should go beyond that. I hope it will.

Could you please outline these directions?

Constantine