[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Parser2 considered harmful
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@m... http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|