SAX2 Namespace Support

[Brett McLaughlin]

David Brownell wrote:
> 
> Brett McLaughlin wrote:
> >
> > David Brownell wrote:
> > >
> > > David Megginson wrote:
> > > >
> > > > In principle (the principle of least surprise), it's very bad
> > > > behaviour for two objects to be == in C++ or equals() in Java if any
> > > > of their publicly-accessible fields differ.  Think of sets, for
> > > > example.
> > >
> > > Actually, it's quite common for nontrivial objects that equals() only
> > > involve a subset of the visible properties.  It's probably even typical
> > > in applications I've worked with.
> >
> > I agree with David B. in theory, but David M. (gee, that's confusing...)
> > in practice.  I think that equality, and assumptions about equality,
> > have some side effects.  For example, if two objects compared through
> > equals() return true, then I expect to be able to use the object
> > interchangeable.
> 
> You expect wrong; sorry.  Look at the spec for java.lang.Object.equals();
> it guarantees quite a few properties (reflexive, symmetric, transitive,
> consistent, ...) but NOT substitutability.  (Use "==" or some specialized
> method for that.)

No... read again:

> > I agree with David B. in <<theory>>, but David M. (gee, that's confusing...)
> > in <<practice>>.

I know what equals() is supposed to do.  However, if we took a poll on
who knows what it is supposed to do, you wouldn't get many "ayes" :-(

I know this is defensive programming.  However, if you _know_ a lot of
people are going to make a mistake, shouldn't, as a good developer, you
try to avoid cases where you _invite_ that mistake?  I don't argue with
your reading of Sun's API.  In fact, I agree (which is why I always
implement equals() and hashCode() in my custom classes).  However, I
know how people think (try writing a book to the masses, and making
assumptions about what people know - not pretty!), and am forced to
acknowledge that.  

> 
> > So I think equals() isn't a good idea; however, something like <code>if
> > (name1.sameNamespace(name2))</code> or something equivalent (not the
> > best example, but you get the idea) doesn't offend my eyes.... for what
> > it's worth.
> 
> Were there to be a Name class that couldn't be used as a hashtable key to
> get the expected effect, then it'd be unusable.  You're suggesting that,
> in effect.

Only to a certain degree; the example was just to say if we want to
provide an equality test for this specific purpose, than I think a
better choice (one that helps people, but doesn't hurt us) would be to
use a more intuitive name than equals().  But yes, using equals() or any
related function carries with it some side effects such as hashtable key
considerations.

-Brett

> 
> - Dave

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 unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)