W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Equality tests on DOM nodes

From: David Brownell <db@Eng.Sun.COM>
Date: Wed, 16 Dec 1998 12:44:22 -0500 (EST)
Message-ID: <3677F04F.391A3B35@eng.sun.com>
To: Ray Whitmer <ray@imall.com>
CC: www-dom@w3.org, xml-sig@python.org
Ray Whitmer wrote:
> David Brownell wrote:
> > Though there's one thing to consider:  The behavior of Object.equals()
> > and Object.hashCode() is specified to make objects work as hashtable
> > keys in the natural manner.  For example, strings can be used as keys
> > since they're immutable and equals() is overridden ... were they mutable,
> > or did they not override equals(), that'd not be so.
> That is a sad but true that Hashtable influenced the implementation of
> Object.  Equals is problematic in Object's API because of its ambiguity, but
> about every other language seems to do something similarly ambiguous. 

I don't see anything being "sad" in the influence you mention.

Any answer that's picked to define "equality" (or "identity") is going to
be pretty arbitrary, and become (in some context/task) "ambiguous".  So there
will always be a need to define application-specific definitions for this. 

I'll also note that after several years (!) of discussion on the topic,
OMG decided to -- gasp! -- let objects be used as keys into hashtables
in CORBA 2.0, as its first foray into the murky waters of this problem.
It's got a low system-wide cost, and provides the benefits folk need.

>	 You
> raise a connection between equals and immutability that I generally tend to
> overlook as nonessential.  There are plenty of other examples in the jdk that
> also overlook it that I cited before (like Point or Rectangle),

There may be no official API policy with respect to immutability, though I'll
ask about that one.  One can adopt a policy (with some imperfect degree of
success) like "if you want to change it, don't use it as a hashtable key...".
I mentioned it to highlight some of the complexity behind the notion of one
thing being "equal" to another -- it could change over time!

> In any case, equals should not be usable for Node until a clear portable
> definition is established, whether that be the identity interpretation or some
> deeper interpretation.

At this point in time, the definition would seem to be the default that's
supported by all java.lang.Object instances.

- Dave
Received on Friday, 18 December 1998 04:06:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC