SAX2 Namespace Support

[David Brownell]

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.)


> 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.

- 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)