[XML-SIG] Re: Equality tests on DOM nodes

[David Brownell]

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