SAX2 RFD: Inheritance vs. Modification vs. Amalgamation

[Steven Marcus]

Hello,

How about using a "marker" interface?

A marker interface defines no methods.  Marker interfaces allow
you to check for new functionality and use the new functionality
without casting. Java uses marker interfaces to signal the
following capabilities: Cloneable, Serializable et al.

So for SAX2:

1) add the new APIs to the org.xml.sax.Parser class
2) create a new empty interface possibly called Parser2, or
better SAX2
3) SAX2 compliant-parsers will implement the new marker
interface as well as all the methods in org.xml.sax.Parser

If you care to use the new SAX2 methods and are not sure that
the parser implements them, just check for the marker interface
in your code. Something like

   if (!(parser instanceof SAX2))
      throw new RuntimeException("need a SAX2-compliant
parser");
   // otherwise use the parser as normal

Catching NoSuchMethodExceptions is very "ugly" (at least in
Java) and I suggest that any solution that requires this is
lacking ...

Thanks!
Steven Marcus
 
--- David Megginson <david at megginson.com> wrote:
> (I'd like to hear from as many people as possible on this
> issue.)
> 
> For SAX2, we need to add at least four methods to the SAX 1.0
> Parser
> interface:
> 
>   public void setFeature (String featureId, boolean state)
>     throws SAXException;
> 
>   public boolean getFeature (String featureId)
>     throws SAXException;
> 
>   public void setProperty (String propertyId, Object value)
>     throws SAXException;
> 
>   public Object getProperty (String propertyId)
>     throws SAXException;
> 
> There are three ways of doing this:
> 
> 1. Create a new interface, org.xml.sax.Parser2, that extends
>    org.xml.sax.Parser.
> 
>    PRO: - provides nice, two-way compatibility
>         - easy to write adapters for existing SAX 1.0 drivers.
>    CON: - subclassing always leads to crime (see the GOF book
> for
>           copious warnings).
> 
> 2. Add the methods to org.xml.sax.Parser, and require
> applications to
>    catch NoSuchMethodException when using the new methods, in
> case
>    they're concerned about what version they're dealing with.
> 
>    PRO: - doesn't limit options for subclassing in the future
>    CON: - very difficult to write adapters for existing SAX
> 1.0
>           drivers (slower acceptance and implementation of
> SAX2)
>         - can cause unexpected behaviour at deployment time,
> unless
>           the application designer knows to catch
>           NoSuchMethodException
> 
> 3. Create a separate interface org.xml.sax.ParserProps (or
> something
>    like that), and require SAX2 drivers to implement both
> interfaces.
> 
>    PRO: - easy to writer adapters for existing SAX 1.0 drivers
>         - fewer nasty deployment surprises
>    CON: - will require lots of casting
>         - conceptually ugly
> 
> Please, comment, comment, comment! I'm not smart enough to
> figure this
> out myself.
> 
> 
> All the best,
> 
> 
> 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)
> 
> 

_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.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)