Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "John Wilson" <firstname.lastname@example.org>, "XML Developers' List" <email@example.com>
- Date: Tue, 9 Mar 1999 07:39:14 -0500
From: John Wilson <firstname.lastname@example.org>
>I don't think that it's unreasonable to insist that objects representing a
>Feature, Handler or Property should either implement a distinct interface or
>subclass a distinct class. If this is so the Parser can tell what Feature,
>Handler or Property is being set by enquiring of the type of the object. (I
>favour insisting that they subclass distinct classes because (in Java) that
>naturally imposes the restriction that a single object can only represent a
Filters often implement more than one (generally all) handler interface and
then register themselves with the underlying parser/filter for the same events
requested by the overlaying application/filter.
Your proposal would require the filter to instantiate seperate objects for each
set of events it needs to process, though it could simply pass-through the handlers
for those it does not.
The role and class of an object are often distinct. This was one of the things I
did not like about the aggregation scheme that was proposed by Sun a while back.
I think David got it right.
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/ and on CD-ROM/ISBN 981-02-3594-1
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)