[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ldt] Re: Beyond textual represenations...
What you are proposing would be better solved by a reusable model that provides base classes for AST nodes.

In interface below getParent() already has equivalent in EMF. getRoot() is trivially implemented over it. The accept() would not be needed as there is already visitor interfaces in EMF. The getStartPosition() and getLength() might be properties on abstract ASTNode base class.

Note that netbeans switched to MDR (a framework similar by its role to EMF) in 4.0. They say that netbeans become faster in 4.0. I do not know if there is any relation. Also I have not worked with netbeans enough to cofirm or deny this.

And I think if JDT will ever switch to LDT, AST representation would be a least of their problems anyway. If LDT will not siginificantly affect code assists, text editors, and other parts of JDT then LDT possibly missed its goal. It means it does not helps in these areas significanly enough to make significant portions of JDT redundant.

Also it looks like there might be JDT DOM implementation that simply wraps EMF-based JDT AST. This might be a way to provide backward compatibility for JDT dependent plugins.

I also think that JDT would actually benefit very much from swtich to EMF. JDT DOM have to do all things that are already perfomed by EMF. It includes parent/child relationships, better than plain Java reflections, generic relationship maintainance etc. EMF does it in robust and automated manner. So extensions to AST will take less time and it would free hands of JDT developers for more interesting tasks.

Constantine

Chris Daly wrote: 
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