XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

> 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.

I'm inclined to think that the root problem is that subclassing is being
used where it's not appropriate. The relationship between XOM and an
application that uses XOM is at heart a server-client relationship. If you
allow yourself to be subclassed, you have to trust the component doing the
subclassing, and a server shouldn't trust its clients. In other words, it's
a bad idea for objects in the application domain to be implemented as
subclasses of Element: the layering is wrong.

I use the same mechanism within Saxon for stylesheet trees and schema trees,
and it works OK because I trust myself. But even there, it can easily lead
to silly mistakes, like overriding a method called getName() because you
didn't realise that such a method existed much deeper in the class
hierarchy.

Inheritance is a very powerful mechanism but also a very dangerous one.

Michael Kay
http://www.saxonica.com/