Re: Equality tests on DOM nodes

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.  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), again
demonstrating the ambiguity of the interpretation of equals, which I think we
are mostly agreed upon.  Users of Hashtable must rely on discipline, because
there is not enough typing to otherwise guarantee that the interpretation of
equals will not change.

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.

Ray

Received on Wednesday, 16 December 1998 11:46:17 UTC