> If you design a grammar that relies on an AST node other than
> CommonTree, such as ANTLR.g3/GrammarAST, then you benefit if the default
> TreeAdaptor creates that node type, so you don't have to specify the
> adaptor every time you instance the parser. :) Once ANTLR generates
> rules that are private unless otherwise specified, it'll be easier to
> set the TreeAdapter in the @init block of the clear grammar entry
> point(s).

Doesn't using a constructor overload suffice for these cases? Also, with a 
property you could still change the TreeAdaptor within an @init-action, if you 
want to keep this information in the grammar.

Johannes
> 
> Sam
> 
> -----Original Message-----
> From: Johannes Luber [mailto:[email protected]] 
> Sent: Thursday, January 15, 2009 2:43 AM
> To: Sam Harwell; [email protected]
> Subject: Re: [antlr-dev] A few things left to implement, plus some
> cleanup suggestions
> 
> > Sixth, there needs to be a convenient way to specify a custom
> > TreeAdaptor for a grammar. The current methods are rather clumsy in
> > general, although the C# 3 target provides a clean workaround. In the
> C#
> > 3 target, there is a virtual function Initialize() called from the
> > BaseRecognizer constructor (I know...), which I override in the
> > ANTLRParser (generated from ANTLR.g3) and a couple other grammars to
> set
> > the TreeAdaptor.
> 
> What's the current method? Using a constructor parameter, right? Why is
> using a virtual call (even if you take care of the pitfalls) better?
> 
> Johannes

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev

Reply via email to