[
Lists Home |
Date Index |
Thread Index
]
- From: David Brownell <david-b@pacbell.net>
- To: Brett McLaughlin <bmclaugh@algx.net>
- Date: Wed, 05 Jan 2000 11:14:23 -0800
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@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|