[antlr-interest] v3.0 debug interface

Thomas Brandon tbrandon at psy.unsw.edu.au
Thu Mar 24 18:27:20 PST 2005


 Yeah, I had slightly confused the two suggestions in that second post.
I think that multicast is pretty essential but yeah the full EventObject
stuff is a little over-the-top perhaps (especially in Java with it's
lack of delegates, when you're using C# style parser.OnLocation +=
handleLocation(EventObject); it becomes more useful, i.e. when you can
easily assign handler methods to events). Presumably if you want to have
events that the ultimate listeners know about that the proxying listener
doesn't know about, i.e. you can make your custom codegen send events
that one of your listening modules knows about but Antlr doesn't, then
you need such a format. If you are worried about the impact on
programmer then one possibility would be a standard
handleEvent(EventObject evt) method that proxied out to location(int
col, int line) rather than location(LocationEventObject evt) methods.
Though you still have the overhead Scott mentions avoiding.

Tom.
-----Original Message-----
From: Scott Stanchfield [mailto:scott at javadude.com] 
Sent: Thursday, 24 March 2005 23:23
To: Tom Brandon; ''antlr-interest' Interest'
Subject: RE: [antlr-interest] v3.0 debug interface

Ter's proposing a unicast observer pattern, rather than multicast (as
Ter's assuming only a single listener). I would prefer a multicast as
well, as this will make hooking up views way easier, and different
people can contribute views independently. Daisy chaining doesn't allow
that.

The debugger(s) will need some sort of notification/registration
mechanism.
In Eclipse, this is easy (plugin registration makes it easy, and we can
define an ANTLR launcher that looks for registered debuggers and
attaches them as listeners to a parser).

If there was a good chance that people would want to wire a debugger to
ANTLR in a JavaBean builder, I'd agree that having it follow the
JavaBean event model (using EventListener and EventObject) would be a
good idea. I don't think that's likely, so I'd avoid the extra event
object creation, and because of that, skip the EventListener extension.

<SNIP>


Here's what I've got for ANTLR 2.7.6's parser listener. I've simplified
it significantly from previous versions. Note the lack of event objects
in this version; I felt they were a waste. Still an observer pattern.

public interface ParserListener {
<SNIP>


Later,
-- Scott





More information about the antlr-interest mailing list