[
Lists Home |
Date Index |
Thread Index
]
On November 9, 2003 11:38 am, you wrote:
> Tyler Close wrote:
> > Could the two sides compromise on a modified SAX API
> > that was defined in terms of a polymorphic string type?
>
> I think this would be a terrible mistake if it requires
> changes to the SAX interface.
Remember that the whole point of the suggestion is that it does not require
such changes (but only for languages that fully support polymorphism). A SAX
handler implementation would be completely oblivious to the change.
Like I said, the Java implementation of the SAX API does not support
polymorphism, so the solution is less elegant here. One possibility would be
to modify org.xml.sax.helpers.DefaultHandler to accept the polymorphic string
type and then redispatch the call to the existing method that takes the
concrete character array.
> Your proposal, if accepted, would require that the many users
> of SAX would have to deal with and be confused by the polymorphic
> string type even if they don't need the benefits it provides. As has
> been pointed out many times in this thread, the whole XML world is
> already too confusing. We can't afford to make it more confusing by
> introducing such complexities.
In a language that supports polymorphism, the users wouldn't even realize that
they were dealing with a different implementation. It's too bad we're working
with languages that don't even support the language abstractions known in the
'70s (or earlier).
Tyler
--
The union of REST and capability-based security.
http://www.waterken.com/dev/Web/
|
