[
Lists Home |
Date Index |
Thread Index
]
- From: Brett McLaughlin <bmclaugh@algx.net>
- To: David Brownell <david-b@pacbell.net>
- Date: Wed, 05 Jan 2000 13:19:27 -0600
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@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)
|