[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.technology.ldt] Re: Beyond textual represenations...
|
- From: Guillaume Pothier <gpothier@xxxxxxx>
- Date: Tue, 22 Mar 2005 15:47:28 -0400
- Newsgroups: eclipse.technology.ldt
- Organization: EclipseCorner
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050116
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.
- it generates Java (only) source code for this structural model
- it cannot represent application logic (ie. method bodies) except for
the structural aspects defined in the model (getters, setters...)
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...
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.
BTW I would like to see something like the ModelDOM componet in LDT.
This component would do the following components:
- Support IDocument-related interfaces (possibly Webtool SSE based)
- Have one-to-one mapping to soruce (So it is a concrete syntax tree
rather than AST)
- Ingegrates parsers/reparsers
- Maintains mapping to EMF-based AST of source code
Sorry not to be that knowledgeable, what is ModelDOM? Part of EMF?
Regards,
Guillaume