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

Scott Stanchfield scott at javadude.com
Wed Apr 20 04:24:26 PDT 2005


To avoid folks whining about the length of digest posts, I'm going to
generically address your misunderstandings...

1) You need to examine the code I posted last night.

2) TreeNode and TreeModel SHOULD NOT be the *actual* data. The should just
be used to ADAPT existing data (again, see the example code -- the GUI I
create and whose components I display in the Jtree *Do not* implement
TreeNode...)

3) ANTLR ISN'T THE ONLY WAY TO CREATE TREES.

I don't want to have to force my data to "be" antlr objects, NOR do I want
to create an adapter PER NODE. Using my proposal, we would be able to
process ANY existing tree (without cycles)

4) You're thinking of a single-pass *program*, which seems to be the same
box Ter is thinking in.
(This is for all of your "the garbage collector is reasonably optimized"
lines. I'm talking about scenarios where the garbage collector will run
hundreds or more times while the program is running)

To make the problem clear:

I want to use this for processing an eclipse AST, as do many of the folks
I've chatted with on the eclipse mailing lists. ASTs will be generated
hundreds or thousands of times during an eclipse session.

Every time you pause during typing, an AST is created for syntax
highlighting and error analysis. I want to create ONE additional object to
interpret that AST with an antlr tree parser for some additional anaysis.
I've brought up on the eclipse mailing lists using ANTLR which was met with
great enthusiasm, but it's WAY too much overhead with the ANTLR 2.0 AST node
req or 3.0 carrier/payload design. It would require an adapter PER eclipse
AST node.

There's no way I'd propose making eclipse ASTs implement ANTLR's AST
interface. I'd be laughed out of the mailing list, because everyone there
knows adapters are the right approach, and that this is only feasible if
ANTLR trees work the same way Swing trees do.

5) As for Swing You TRULY do not get Swing's tree.

TreeNodes are **optional**. YOU DON'T NEED THEM TO DO JTREE. See the example
code I posted for how you SHOULD do adaptation of an existing structure.
(See the GoodExample.java)

You have a CHOICE in swing:

a) Use the existing DefaultTreeModel and adapt existing data using TreeNodes
   Cost: an extra tree node adapter PER real node

b) Use the existing DefaultTreeModel and change your existing data to
implement TreeNode
   Cost: modification of real data nodes, injecting a Swing dependency into
them
         * you may not have access to modify them
         * I think it's bad design to integrate the presentation model 
           (TreeModel/TreeNode) with the real model
         
c) Use your own TreeModel (without TreeNodes) to adapt the entire tree
  Cost: ONE new object. The data doesn't change

> > Jtree  --> TreeModel --> Your Real Data
> Which implements the TreeNode interface ...

NO!!!!! The data DOES NOT NEED TO. You obviously didn't look at my example
code.


Ter -- please look at the example I posted. I hope you "get it" and
implement this for 3.0. Otherwise I'll need to maintain a mod to ANTLR that
I'd really rather not.

This is no extra cost to ANTLR or use of ANTLR ASTs, but it opens up ANTLR a
whole new realm of application.

Frustrated,
-- Scott







More information about the antlr-interest mailing list