Parser2 considered harmful

[David Megginson]

John Cowan writes:

 > The [insert a certain W3 WG] folks have been deciding what to do
 > about extending their interfaces xxx.Foo and xxx.Bar (not their
 > real names) while adding a new level of their standard.
 > 
 > They seem to have settled on just adding methods to the existing
 > interfaces, a form of evolution which Java directly allows, and
 > which works well in dynamic scripting languages (Javascript, Perl,
 > etc.)

Yes, I believe that a similar point came up during our SAX-naming
discussions earlier.

 > COM implementations (which are not directly prescribed by the
 > standard) will probably use Foo2, Bar2, and so on, because of
 > special COM considerations, but that will not affect the standard,
 > which will merely document at exactly what level (1, 2, etc.)  a
 > given property or method was added to the standard.
 > 
 > I think that the use of Parser2 should be reconsidered in favor of
 > just extending Parser.  There are several arguments:
 > 
 > 1) Either Parser2 inherits from Parser or it doesn't.  If it
 > doesn't (and underlying objects just implement both interfaces)
 > then much casting must be done to get the right flavor to call a
 > method on.  This is very expensive in Java.

Actually, that wouldn't matter in any significant way, since the
casting would have to be done only once for each document parsed
(Parser is a top-level entry point).  I wouldn't worry about what is
or isn't expensive until we were dealing with code run repeatedly in a
tight loop or for each parse event.

 > If they do inherit, then you have the problem that Parser may be
 > extended in several logically distinct ways, leading to interfaces
 > Parser2A and Parser2B.  The next generation will have to specify
 > Parser3A, B, and C all inheriting from Parser2A *and* Parser2B,
 > which causes a messy diamond-shaped inheritance graph.

That's the main reason for the shift to get/setFeature/Property --
while it screws around with type safety a little, it should eliminate
(most) of the need for subclassing Parser2 any further.

The main point is that, while XML itself is stable, what people want
to do with XML is not -- if SAX is going to move forward, we need
something open and extensible, so that some parsers can introduce and
support new features without messing around with the Java class
signatures.

 > 2) Applications written to run against SAX1 Parser can be linked with
 > SAX2 Parser with no issues.  Applications written to run against SAX2
 > and linked with SAX1 parsers can run in degraded mode by catching
 > a NoSuchMethodError or its equivalent when trying to use SAX2
 > features.  With Parser2, the application would die with
 > ClassNotFoundError.

It's possible to test for the availability of a class in Java, if an
application writer were worried about that -- what it really comes
down to is the fact that you'll always have to use some kind of try {} 
catch {} statement if you're worried about whether SAX2 is available
in your environment.


All the best, and thanks for the comments,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)