API thoughts...

[Bill Smith]

> Well, the Lark event-stream API sure looks & feels like a bunch of
> callbacks.  You make a Lark object, call its readXML() method with one
> argument being a Handler object; Handler being a data-less class that
> just has a bunch of methods called things like doPI() and doStartTag() and
> doEntityReference() and doText() and so on; you'd normally subclass Handler
> replacing the methods for the events you wanted to see, and pass in
> that kind of object.  Lark calls these upon recognizing
> the constructs in the input stream, passing the byte offset info, the 
> element & entity stack (*if* you're treebuilding), and other currently 
> relevant info.  These methods are all booleans; if any returns true, 
> Lark stops and returns control to whoever called readXML().

Another way to do this is to have the Lark object (or interface) define the
event methods rather than have a separate Handler object. When it's time to
parse something, create a subclass that overrides the (standard) event methods
for the Lark object.

A possible advantage to this method is that it makes clear the inheritance
relationship between the "standard" parser and something more specific. It
is also "easier" to create a more specific parser from an exisiting parser
object - simply subclass the existing parser and override the methods
required to provide the desired new functionality.

The Lark model "hides" the inheritance relationship in the Handler object
making it necessary to look inside a Lark object to determine the type of
a given parser (something you might need to do when debugging). An 
alternative is to create a new parser object that contains a subclassed event
handler. This makes it possible to distinguish the type of parser at the
"outer" level but requires two new objects instead of one to perform the
subclass.

I'm not a parser expert so the subclass model may not make any sense but this
is a mechanism I have successfully used building other object-oriented
(including GUI-based) systems. I have also used callbacks but find them most
useful when forced to use C or other non-object-based languages. 


xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)