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

[Chris Daly <cjdaly@xxxxxxxxxx>]

On the use of EMF for ASTs and the JDT's current AST implementation:

I think that EMF would be a great framework for generating AST classes 
for languages, but I would hate to have it be the only supported way.  I 
also don't think JDT should have to switch to EMF just to "play" in LDT.

Take a look at org.eclipse.jdt.core.dom.ASTNode.  It is an abstract 
class, but I see the beginnings of a good IASTNode interface there:

interface IASTNode {
  IASTNode getParent();
  IASTNode getRoot();
  void accept(IASTVisitor);
  int getStartPosition();
  int getLength();
}

Why not start by pulling interfaces like IASTNode, IAST, IASTVisitor, 
etc. out of the JDT classes (and then making those classes explicitly 
implement the interfaces)?  It seems to me this could be done without 
breaking API (though you would almost surely need to add to the API, 
like getChildren()).

Then EMF users can tweak their generated code to also implement IASTNode.

I realize there are a lot of tricky details here, but it seems to me 
like it's worth a closer look, especially because it would bring JDT 
along without too much fear of destabilization.

Chris


Constantie Plotnikov wrote:
> Mike Kaufman wrote:
>
> > Yes, I think this is a good compromise.  I think that part of the 
> > LDT's intial effort is going to be define APIs for a generic AST.  
> > Consequently, tools can be written to the API to operate on a 
> > language-neutral AST.
> >
> > Persisting this AST is orthogonal to these APIs though, and I'm not at 
> > all aware how the plugin you describe would be written.  And, it feels 
> > like a pretty large effort to build a plugin to have eclipse persist 
> > ASTs instead of text files.  I do think though, that such a plugin 
> > would be a client of the LDT APIs though, and not part of the LDT itself.
> 1. JDT DOM API is too Java dependent now. Changing it to make it more 
> generic would break clients anyway. So it might make sense not become 
> too fixed on JDT. A new API that is JDT other might be used.
>
> 2. EMF project (http://www.eclipse.org/emf) already provides a generic 
> model API. Usual AST there is result of parsing some document would 
> usually underuse EMF features. This API natively supports persisting as 
> XML. As I understand there is a work underway to support persisting to 
> the database. It also natively supports event notifcations and with some 
> efforts undo/redo through commands.
>
> I cannot say that EMF is perfect. But a lot of efforts is invested in it 
> and new AST API would just duplicate these efforts.
>
> 3. The competing to eclipse.org project named Netbeans have a competing 
> to EMF framework named MDR (http://mdr.netbeans.org). As I heard, this 
> framework is used to implement part similar to JDT AST in netbeans 4.0 
> (see http://mdr.netbeans.org/javamdr/).
>
> Constantine