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

[Scott Stanchfield]

First, I don't know if you realize that the Carrier model you propose is
*exactly* what TreeNodes are in Swing.

Swing allows you to do exactly what you're saying, *but* gives the option of
replacing the entire tree model yourself. This is TreeModel.

As usual, *I'm asking for an option* and getting shot down because y'all
don't happen to need it in the little boxes you're living in. Think bigger!

(Give me the *option* of not having to type the damned parens for + and
*!!!!!!!!!!!)

I'll write up an example so you can really see it in a few mins...


> Separating data and navigation interfaces is key to 
> supporting any sort of transformation--to transform, you need 
> to rewrap a data package with navigation information. 

This is *exactly* what the ASTModel I'm proposing does.

Think about it this way

1) We have some "tree data". The data can be in *any* tree form you like,
but we'll assume there are no cycles to avoid that argument for now

2) We want to parse the data using an antlr tree parser

3) Antlr needs to determine
   a) the token type of a node
   b) the children of a node
   Note that Antlr really doesn't need to know the *class* of the
   node as long as it can get this data.

4) We provide a mapping layer between Antlr and the data that interprets
Antlr's requests by looking at the real tree data and returning it.

5) Suppose antlr needs to create or modify nodes

6) we provide another mapping layer that interprets antlrs requests (create,
add/remove kids) by manipulating the real data

Perfect separation. Only ONE extra object needed to do the job instead of n
extra objects.

With a big tree, the overhead of carriers is significant.


> Swing's JTree is mis-designed because the navigation class 
> (JTree.DynamicUtilTreeNode) is referenced from the data 
> container, not the other way around.

Huh? Which Swing are you talking about? What do you mean by "navigation
referenced from the data container"? It's not. The navigation data
(TreeModel) is separate from the data, and is only called from the Jtree
(the presentation). The real data doesn't call the tree model.


Swing has a brilliant design for the tree that gives great model separation
from the UI.

JTree
  |  calls
  |
  V
TreeModel
  |  calls
  |
  V
Your real data

Think of TreeModel as a controller for the actual data, which is the real
model. All access to the data from the UI goes through the tree model. The
real data doesn't (and shouldn't) even know the TreeModel exists.



> There are two navigation
> paradigms:  you can either use a Cursor object to navigate 
> (in which case, the options are assigning an object to the 
> cursor, moving the cursor to one of the siblings or children 
> of the assigned object, returning a sibling/child of the 
> assigned object, or adding a child/sibling) or a Carrier.  

You're thinking in a box and missing a better option. The ASTModel option is
a complete separation of cursor and navigation.

Take the Jtree example.

Jtree asks the TreeModel for the root node, and holds that root node. This
is the "current node", or cursor.

Jtree renders the current node

Jtree asks the TreeModel to tell it the # of children, and asks for each in
turn. As it asks for each, they are the cursor. It renders them.

This is a really flexible and less expensive solution.


> [example snipped]
> That may look like a lot of overhead to create Carriers 
> willy-nilly, but in practice it probably is not--the creation 
> and destruction of Carriers is just a recycling which the 
> garbage collector will do as efficiently as one can do 
> manually or nearly so--when walking, Carriers are the only 
> dynamic element.

The trouble is there are extra objects to collect. More objects == more
frequent/longer collection == slower app. In the ASTModel example, there is
*one* ASTModel.

> Really, it is all just a matter of which access pattern you 
> are using, and the key abstraction is to separate out data 
> from navigation.

Later,
-- Scott