Hiya. GeraldHas brought up an excellent point about our runtime. Currently, parsing errors get reported through method reportError. To do something different, you have to override that method. Gerald is suggesting that we move to an error listener mechanism so that multiple listeners can attach to a running parser and receive error events (kind of like what we do for debugging events).
I'm all for this idea, but what about backward compatibility? a lot of people have overridden reportError in their parsers or tree parsers (like me) and we want that to continue to work. How do we integrate this with a listener mechanism? Also, Gerald points out that even if someone overrides that method, his tool and other tools for integration with eclipse need to get those errors regardless of whether someone has overridden reportError. Otherwise, the ANTLR IDE couldn't get syntax error messages when it ran. He suggested > Preferably, the listener interface would be above anything that the end user > could override. Stuff that now calls reportError should instead call some > private "reportError_intern", which fires the event listeners and then calls > the public/overrideable "reportError". any comments on the approach or what we want? The minute I get v4 running in v3, I want to turn around and have v4 generate its own parsers. Backward compatibility will also be important for me. Ter 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.
