At 04:12 17/04/2009, Paul Bouché (NSN) wrote:
>In the past I would have liked the same, but....
>As a workaround you could add for each parser
>method an @init and @after which calls some
>custom added methods (in the @members section)
>which are non-final, have some default behavior
>and can be overriden in a subclass of a parser.
>I think this is the closest you can get to
>"overriden parser methods" out-of-the-box. And
>also some action methods.
>
>I.e. with Java-target
>
>@members {
> public void fooInit() { }
> public void fooAfter() { }
> public void fooBAR() { }
>}
>foo
>@init {
> fooInit();
>}
>@after {
> fooAfter();
>}
>:
>BAR { fooBAR(); }
>;
Another option is to have your action code call
an interface provided to the parser rather than
taking any direct action. You can get all the
flexibility you want that way.
(Although even then, it might be better to
generate an AST and have alternate tree walkers
for each separate task you want to perform.)
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
