XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

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.