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: "Michael Kay" <mike AT saxonica.com>
  • To: "'Wolfgang Hoschek'" <wolfgang.hoschek AT mac.com>, "'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: Fri, 6 Jan 2006 00:22:44 -0000

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






Archive powered by MHonArc 2.6.24.

Top of Page