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: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: John Cowan <cowan AT ccil.org>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM and the methods of Object class
  • Date: Thu, 05 Jan 2006 13:36:18 -0500

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.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




Archive powered by MHonArc 2.6.24.

Top of Page