Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM and the methods of Object class

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: John Cowan <cowan AT ccil.org>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM and the methods of Object class
  • Date: Thu, 5 Jan 2006 15:02:52 -0800


On Jan 5, 2006, at 10:36 AM, Elliotte Harold wrote:

John Cowan wrote:


XOM violates this second expectation in its declarations of these method.
Consider the toString() method. The JavaDoc for Object class recommends
that toString() returns a string which is "a concise but informative
representation which is easy to read." Now an object may be made a
subclass of of Element in order to give it a natural representation
in XML. This does not mean, however, that the most informative
representation is one that is suitable for a generic XML element.
If the class is an application class, a suitable representation ought
to be relevant to the application.


That change has already been made in Element in CVS at Steve's request.
I wouldn't be hugely averse to making the change elsewhere if someone
actually needed it.


Likewise, the various equals() methods require that all subclasses of XOM
classes use identity (==) as the meaning of equality. This means that no
subclass can function as a value class, because in value classes (String
is a familiar example), equality is defined recursively as part-by- part
equality rather than mere identity. This is an unnecessary restriction
on the freedom of application developers. If there are parts of XOM
that depend on this definition of the equals() method, they should be
rewritten to use == directly.


This is a lot more serious. I'd need to check the XOM internals pretty
carefully to make sure this is true. My concern is not so much direct
use of equals(), as it is HashMaps and similar data structures, as well
as third party code that depends on this contract. It's also been my
experience that allowing subclasses to override equals() tends to
violate the transitivity of equality. That is, it's very easy for
a.equals(b) to be true but b.equals(a) to be false.

I'm not saying I couldn't be convinced here, but you'd need a damn good
use case to convince me.

I guess noone would propose to change the semantics of int ParentNode.getChildCount() to suddenly return the total number of resursive descendants in the entire subtree? Or to change String.equals() to compare while ignoring leading and trailing whitespace. Or having a Map implementation that always throws an exception on map.size() or returns twice the number of entries on map.size(). Contemplate giving such a map instance to unsuspecting folks who expect it to be any kind of generic map?

But that's really no different than removing final from Node.equals() and Node.hashCode(). Although the API signatures remain the same, the semantics are (or may now be) completely different, voiding all guarantees and assumptions, breaking existing codes everywhere in random places.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page