Re: Equality tests on DOM nodes

Paul Butkiewicz wrote:

> A further implementation difficulty has occurred to me:  There are likely
> many people out there who would like to or are using the DOM in conjunction
> with a database, making the node objects persistent.  These folks would
> probably prefer that equality indicate not just that two nodes are identical
> but that they represent the same record in the database.

While this would be a useful function, I don't think it makes sense that it
should be the function of "equals".  But it does point out the many possible
interpretations, which was the point of my original response.  As I stated
before, overriding equals would be a bad idea without an agreed-upon portable
interpretation.  People wonder why some of us are not sad that Java doesn't
support general operator overloading, which would add yet another whole set of
such ambiguities as "equals" provides.

> I must be feeling contrary today, but I think you're saying isn't true.
> String.equals( String ) does examine the contents of two different objects
> to determine that they are identical.  But this is the case only because
> String explicitly overrides the equals( Object ) method in Object, which
> isn't true of many objects.  The equals( Object ) method in Object only
> returns true if the objects are actually the same object, ie.
> ( *x )->equals( *y ) if and only if x == y.

The point of equals is so that it can be overridden with a deeper,
class-specific interpretation.  While Object it is too incomplete for a good
deeper sense of equality, equals is only really useful with a set of classes
where it is overridden in at least some of the classes to provide a deeper (but
still consistent, transitive, symmetric, reflexive, useful) sense of equality.
Otherwise, just use the "==" operator.  Not only is the Object implementation of
equals redundant with the "==" operator, but it is also less efficient.

Ray Whitmer

Received on Friday, 11 December 1998 16:02:02 UTC