[
Lists Home |
Date Index |
Thread Index
]
- From: Stefan Haustein <haustein@ls8.cs.uni-dortmund.de>
- To: "Clark C. Evans" <clark.evans@manhattanproject.com>
- Date: Fri, 14 Jan 2000 15:08:46 +0100
"Clark C. Evans" wrote:
>
> On Thu, 13 Jan 2000, Tim Bray wrote:
> > Yes. Given that *every* credible parser does this, and that it's
> > a major convenience for programmers using the API to be able to compare
> > strings with ==, there is at some level an argument that we ought to
> > expose this fact.
>
> There are going to be lots of server side filter
> architectures using the SAX interface which may
> not do this. Indeed, I'd say that the "parser"
> interface is mis-named. It's really an "emitter".
> And I'd go so far to say that in a few years,
> 99% of the "emitters" out there won't be parsers!
>
> So, requiring the authors of those emitters
> to be aware of Java "intern" is streaching it.
Maybe we could agree on interning if a simple unsynchronized local
interning hashtable (able to work on String, char [] and StringBuffer
parts) is
included in org.xml.sax.helpers?
My original argument was that interning would simplify namespace
comparison
since namespace == null can occur in attributes.
> and compile it as
>
> ( lhs == rhs | lhs.equals(rhs) )
(lhs == rhs || lhs.equals (rhs))
seems difficult for a java compiler: you could implement equals
returning
false allways, e.g. in a kind of "Random" object :-)
However, you can add
if (this == rhs) return true;
to your equals implementation (ok, for String SUN should do that if not
already done).
--
Stefan Haustein
University of Dortmund
Computer Science VIII
www-ai.cs.uni-dortmund.de
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|