- From: David Brownell <db@Eng.Sun.COM>
- Date: Wed, 16 Dec 1998 12:44:22 -0500 (EST)
- 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