Lists Home |
Date Index |
- From: Paul Prescod <email@example.com>
- To: firstname.lastname@example.org
- Date: Sat, 03 Jan 1998 20:50:06 -0500
David Ornstein wrote:
> My point is about a relationship: as the usefulness of the base class
> climbs towards necessity, the probability of people using SAX-implementing
> parsers *that don't come with the base class supplied* declines. This is
> only important iff the design of the API is influenced by the assumption of
> the presence of the base class. Some of the "design issue" posts seemed to
> me to be heading in that direction. If we divide the world into SAX
> implementors and SAX clients, I think that the base class is a useful thing
> for *clients* to build and use; it's how I'd do it. As such, I think it
> probably doesn't belong on the implementor side of the line.
If SAX implementors are required to provide a base class, clients could
use it through delegation or inheritance, depending on the language. If
implementing a SAX client is going to depend on this base class, then we
must specify its behaviour and require its existence, however.
Life would be easier if we did not depend on it. One way to do this is
to use the common event-handling idiom of returning "false" or "null"
when you want the caller to do the job. So, for instance a
"fetchEntity()" method might return NULL to indicate that the client
wanted to leave it up to the SAX implementation.
Yet another way to do it would be to require the registration of objects
for the handling of more complex events:
registerEventFetcher( EventFetcher fletch );
Art is always at peril in universities, where there are so many people,
young and old, who love art less than argument, and dote upon a text
that provides the nutritious pemmican on which scholars love to chew.
-- Robertson Davies in "The Cunning Man"
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)