[antlr-interest] Yet another idea for a completly genericTreeParser

[Scott Stanchfield]

The penalty is negligible (an extra method call which usually doesn't do
much but call a method in the real model.

I just thought of the real drawback here. You have to generate multiple
times to deal with different trees.

The bigger problem IMHO is coding-time compiler checking. With an adapter
solution (what I proposed), the adapter gets full compile time checking
against the AST Model interface *and* the target data structure.

With the code gen approach, everything is strings, and they could be rather
spread out.

Also with the code gen, you can really only do very direct translations that
Ter anticipated and provided hooks for. Using the ASTModel approach, you can
do whatever you want behind the scenes.

The key problem is:

> Loring and Monty and I discussed something like this for 
> tokens and ASTs at the Oregon ANTLR cabal.  But we thought in 
> terms of what properties you could have.  Perhaps we should 
> go further and specify the templates used to do common 
> operations.  For example, here's one kind of tree access 
> using ST notation:

You need to anticipate all the hooks instead of just exposing one simple
interface.


BTE: You should use generics in JDK 1.5.0. No more casting...


Why is the AST model approach so abhorrent to y'all??? I don't get it. It's
clean, simple, has several precedents, and is a simple application of a
common design pattern.

What are the problems with the ASTModel approach??? The *only* theoretical
problem is an extra method call, and let's face it, an extra method call is
negligible.


Why add complexity of code generation when the same problem can be solved by
exposing a single interface for the entire tree.

[LORING - Don't bother to reply to this post as we will obviously never
agree on this.]

PLEASE JUST MAKE IT AN OPTION!!! That's all I'm asking!

Later,
-- Scott