XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 1/6/06, Michael Kay <mike AT saxonica.com> wrote:
> > 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.

'dangerous', not bad. It does happen to be exceedingly powerful.

To an extent, the semantics of equal/hashCode/clone are trouble,
because they are required to have consistent behaviour across so many
things, yet most people get them wrong. And if two uses of them have
different expectations, then there are incompatible goals.

clone is the worst example, as it doesnt really work as intended; Xom
sorts this out by having a different copy/clone mech with proper
override points. I'm not going to advocate doing the same for
equals/hashCode because all the standard map classes assume they are
there to use. (Compare with C++ STL stuff that I distantly recall let
you specify your own functions for those operations)

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

That's Java for you. C# doesnt have that problem; @Override is meant
to fix it, but since it's optional, its irrelvant. Anyway, if it or
"virtual" was required for overriding, this mail list would be full of
people going "please can you make method Y virtual"

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

The best things always are :)

As an aside, I am debating whether we need a litte annotations project
somewhere where you can mark methods/classes as unstable/dangerous.
All there is today is @deprecated, which is effectively the first of
the java5 annotations, as it remains in the binaries.

It would be nice to let someone mark up their code

@unstable("may go away on a whim")
public void doSomething()

@dangerous("this operation has O(e^^n) delays")
public void enumerateUsers()

@thread-unsafe("this doesnt get a lock for performance, but can return
an incomplete view of the world")

These tags would go in the binaries and so could be extracted/used in
some code auditor to find out all thread-unsafe, dangerous and
unstable operations.

-steve