ModSAX (SAX 1.1) Proposal

[James Clark]

Don Park wrote:
> 
> >The ModHandler class seems particularily useless.  It just creates a
> >completely unnecessary dependency between handler classes and the SAX
> >package.  You could use Object just as well.
> 
> Two reasons:
> 
> 1. Using java.lang.Object will make ModSAX Java-dependent.

But SAX already uses java.lang.String.  How will avoiding
java.lang.Object reduce the degree of Java dependency?  When translating
into other languages, you already have to translate java.lang.String
into the appropriate type (eg BSTR for COM)?  You can do the same for
java.lang.Object (eg use IUnknown for COM).

> 2. Using ModHandler interface adds some compile-time type-check.

Using ModHandler doesn't provide type-safety.

Suppose I do:

parser.setHandler("org.xml.sax.namespace", nsHandler);

Now the handler org.xml.sax.namespace will need to be of some specific
type, org.xml.sax.NamespaceHandler, say.  What needs to be checked is
that nsHandler is of type org.xml.sax.NamespaceHandler.  Using
ModHandler doesn't do that.

In fact there's a much higher degree of type-safety not using ModParser
and ModHandler at all.  Take my example again:

interface PingParser extends Parser {
  void setPingHandler(PingHandler handler);
}

interface PingHandler {
  void ping();
}

void registerPingHandler(Parser parser, PingHandler handler) {
  try {
    ((PingParser)parser).setPingHandler(handler);
  }
  catch (ClassCastException e) {
    // it doesn't support Ping
  }
}

There's no possibility here of passing the wrong type of handler here to
setPingHandler.

James



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)