[antlr-interest] On trees and JavaBeans, part 2: tree creation

[Micheal J]

> Hi Guys,
> 
> I like the flexibility of swing's tree interface, but I don't 
> like the 
> need to pass in the parent to get the child.
> 
> Tree t = tree.getChild(parent, i);
> 
> just seems less pleasant than
> 
> Tree t = parent.getChild(i);

I'm sure you agree this is a minor point  ;-)

> Also, you still need a tree node of some kind to actually implement a 
> tree.  Perhaps Tree and TreeNode?

Perhaps but a TreeModel-style interface doesn't care or know about the
concrete types. That is encapsulated in implementation classes.

> I'm open to suggestions still because the payload model requires an 
> extra node just to wrap the pointer (as an "adaptor") to another kind 
> of tree node.  For example, if you have a DOM tree or something that 
> doesn't directly satisfy the Tree interface, you must 
> essentially make 
> a duplicate, parallel tree that points node-for-node from the ANTLR 
> tree into the DOM tree.

The Carrier/Payload model is no better or worse than the requirement to
implement AST currently w.r.t accomodating existing foreign tree/node
classes (that can't be modified to implement AST). It solves a different
problem.

> The main issue for me is: when do you really want to walk a "foreign" 
> (non-ANTLR constructor) tree?  It happens sometimes, but usually 
> because you're building your own trees with actions, which you could 
> make implement the Tree interface easily.  It would be fairly rare 
> don't you think to want to walk a totally unrelated data structure?

My main question is "does the use of a TreeModel-style interface have any
significant performance costs compared to the Carrier/Payload model?".

It's main benefit would be that ANTLR can work with [almost?] any
representation of trees. We would supply a CarrierTreeModel or
DefaultAstTreeModel implementation as default that works with the default
Carrier/Payload interfaces.

The ASTFactory would need to be extended as in Scott's 1st post to offer the
same flexibility in tree construction. Only the factory implementation
classes would know the true representation of the trees. We would once again
supply a DefaultAstFactory that creates Carrier/Payloads.

> The payload thing works GREAT in most cases as it just points at the 
> associated token :)

This wouldn't change if a TreeModel-style interface was adopted.

Cheers,

Micheal