[antlr-interest] On trees and JavaBeans, part 2: tree creation
open.zone at virgin.net
Wed Apr 20 03:07:56 PDT 2005
> > Swing allows you to do exactly what you're saying, *but* gives the
> > option of replacing the entire tree model yourself. This is
> > 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
> > > 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.
> > 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.
More information about the antlr-interest