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

[Micheal J]

Loring,

> > 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!
> 
> Wrong!  You've got your blinders on and are chasing windmills 
> as a result. Complexity for complexity's sake is not good 
> design.  The Carrier/Payload model provides all of the 
> capability that you are campaigning for.

Not quite. Tree navigation classess must implement the Carrier interface.
Arbitary tree representations are therefore not supported. A TreeModel-style
abstraction would remove that restriction and, it would still wok perfectly
with the Carrier/Payload model.

> > > 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.
> 
> No.  The data container implements TreeNode; TreeModel just 
> provides an access model which hides that ugly fact.

The data container doesn't *have* to implement TreeNode. You could have
separate TreeNode and Payload instances (the data container) and the
TreeModel abstraction would still work fine.

TreeModel isn't bound to (and doesn't know about) TreeNode.

> > > 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.
> 
> No--it is a solution that provides the required complexity 
> for the problem that it solves.  At the lowest level, 
> TreeNodes are quite analogous to ASTs and have all of the 
> associated warts.  TreeNodes, however, tend to be persistent, 
> while AST nodes have to be copied during each transformation 
> pass.  ANTLR trees have different associated costs than Swing trees.

In the context of the discussion about introducing a tree abstraction into
ANTLR, this comments about TreeNode and Swing trees are strawmen. A
TreeModel-style abstraction has no dependence on TreeNodes or Swing trees,
it could use Carriers/Payloads (or indeed our old-style ASTs) directly if
that is all one cared about.

> > The trouble is there are extra objects to collect. More objects == 
> > more
> 
> You miss the point.

Yes he does. A TreeModel-style abstraction isn't an alternative to the
Carrier/Payload model. It is a façade that allows one to use Carrier/Payload
or any other model one cares to implement.

> There is less manipulation of data 
> pointers with Payloads implemented as objects distinct from 
> Carriers when doing significant manipulations.  Objects 
> created and destroyed are homogeneous, which places less 
> stress on the garbage collector resulting in faster creation 
> times and fewer compactions.  And, for platforms that do not 
> have efficient garbage collectors, releasing Carriers back to 
> a CarrierFactory is possible.

Indeed.

> > is
> > *one* ASTModel.
> 
> ... and many ASTNodes, which makes it necessary to copy data 
> fields during tree transformations, and that costs in terms 
> of performance.

Not quite. An ASTNode abstraction might mix navigation and data or, it might
separate them as the Carrier/Payload model does. It isn't accurate to claim
that it is *neccesary* to copy data. That obviously depends on the [tree]
node abstraction in use and the use of a TreeModel-style abstraction doesn't
change that fact.

>  You cannot avoid costs associated with 
> navigation; however, you can minimize the cost of maintaining 
> AST data across transformation passes.
> 
> For that matter, you can allow ASTs which implement both the 
> Carrier and Payload interfaces for single pass language 
> processors.  Don't confuse interfaces with classes--logical 
> and physical structures can be quite different.

I could offer the same advise to you Loring  ;-)

A TreeModel-style tree abstraction can be implemented to use the
Carrier/Payload model. Other tree navigation/data models can be
implemented/supported just as easily.

Cheers,

Micheal