Abstract Syntax Trees

Last revised 12:05 Friday September 14, 2001

Original work item: "Exposing the AST API."

Related work item: "Improved Java code manipulation support, address JDOM limitations; JDOM doesn't preserve markers and isn't document aware; JDOM finer grained update support (e.g. change method name, type name); buffer contents is duplicated in Java UI document and needs to be manually synchronized."

Background

Dirk's wish list with regard to the AST support:

Summary from Sept. 10-11 meetings

Dirk travelled to SNZ to discuss refactoring requirements and possible solutions with Philippe M. and Jeem.

Some of the forms of solutions discussed, but ultimately abandoned:

In the end, we agreed on AST plus bindings: AST will either extend or replace JDOM. In the latter case, JDOM would be deprecated.

AST will exist along side Java model.

AST Node Types - Classes, interface, or both

There are on the order of 87 node types for Java ASTs. Bindings will add some more. There are a couple of way this can be mapped to Java types.

(1) Use org.w3c.DOM interfaces as API. Provide a private concrete implementation of the DOM.

Pro: Very small, and standard API for read-write documents.
Con: API is not convenient for clients.
Con: API is not amenable to exposing bindings and other non-structural information.

(2) Concrete API class per AST node type.

Pro: API as small as possible.
Pro: Client can create nodes directly.

Con: Cannot easily hide implementation details; e.g. representation and mechanism for reassembling compilation unit text after editing; lazy binding creation.

Clients who create node from scratch only ever need basic constructors (the nodes they create do not have source positions, bindings, or other decorations). On the other hand, the parser needs to remember more info including fine-grained source positions.

(3) API interface per AST node type, along with node factory methods. Provide a private concrete implementation. Allow clients to reimplement node types (from scratch) and supply a factory.

Like JDOM (except JDOM does not permit client to reimplement) and org.w3c.DOM.

Pro: API as small as possible.
Pro: Easy to tailor different kinds of representation: read-write vs. read-only ASTs; raw ASTs vs. AST+bindings.

Con:  Hidden concrete implementation classes takes more space.
Con: Using factory methods is a bit less direct than using constructors.

We should go for this last option and provide API interfaces with hidden implementation classes.