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

Scott Stanchfield scott at javadude.com
Wed Apr 20 20:15:51 PDT 2005


> The "overhead of carriers" as you put it is similar between 
> the current Carrier/Payload model and any other tree 
> representation you propose that also separates navigation and 
> data. It's worth remembering that Carrier and Payload are 
> abstractions (i.e. interfaces).

Nope. The thing I'm saying is that because we're regnerating the AST
hundreds of times per session, that means we'd have to generate the carrier
adapter implementations for those over and over again, which means they get
collected over and over again.

It's not the number of times the GC runs that's the problem; it's the number
of objects that the GC will have to collect.

> Adapters are NOT *always* the right approach as you seem to 
> be suggesting but,

I'd never suggest that one pattern is the best for all programming problems.
But for this example (eclipse asts) it's the obvious choice.


> > This is no extra cost to ANTLR or use of ANTLR ASTs, but it 
> opens up 
> > ANTLR a whole new realm of application.
> 
> Actually there is a cost as it involves at least an extra 
> level of indirection on each access. True, it's a minor cost 
> in most cases but, it exists nonetheless. I'd argue however 
> that the benefits to ANTLR and it's users of this flexibility 
> outweigh the cost.

Actually you're right (on all counts).

ANTLR -> DeafultASTModel -> Carrier -> data
ANTLR -> Custom ASTModel -> data

vs

ANTLR -> Carrier -> data

And as you say, the cost is negligible.

Later,
-- Scott






More information about the antlr-interest mailing list