API thoughts...

[Tim Bray]

At 10:00 AM 3/5/97 -0800, Bill Smith wrote:
>The term "callback" doesn't make much sense in Java since (if I remember
>correctly) you can't pass function pointers in Java 

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().

Surely the GUI experience has taught us by now that a callback interface
is the way to go... anyone remember [shudder] XNextEvent()? 

I am somewhat amused by all the Java propagandists saying "Java is so 
much safer because we don't have pointers"... of course most variables
are in fact object pointers, and every object is in fact an Object, and
every array is in fact an Object, and you sure can wreak some good 
old-fashioned C-style destruction on yourself when you accidentally
treat a pointer to a "byte[] foo" (oops, an object not a pointer)
as an oops-an-object-not-a-pointer-to-a "char foo[]".  Still,
java is appealingly clean.

Note for XML developers... I just finished putting correct attribute
defaulting (internal subset decls only, sorry) into Lark (new version
soon) - it nearly doubled the number of parsing states and class file
sizes... sigh. 

On another subject, I really have trouble with trying to pretend
that Element and Attribute and Entity and so on are just flavors
of some abstract Node thingie - the idea of having separate 
classes/objects for these things just feels natural at a really deep
level.   One of the *nice* things about SGML and XML is that even
if the markup is complicated, the number of underlying objects is
pretty limited and maps neatly into a class framework. - Tim


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)