XOM API for Processing XML with Java

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

On 12/9/05, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
> Steve Loughran wrote:
> > Given that it is primarily for debugging, why is Element.toString() final?
> >
>
> It's final because everything should be final unless and until there's a
> clear and compelling use case for subclassing/overriding it. So far no
> one has demonstrated such a use case or shown a need for overriding it.
> if someone does, then I'd consider making it non-final.

ok. here is a use case.

1. An IDE debugger that automatically calls toString() on objects to
let people see what the contents of java objects are.

2. A Xom-based document graph containing custom elements with extra
attributes and state.

3. code using the graph to do a fairly complex graph reduction,
copying in referenced fragments from elsewhere, cloning bits, merging
attributes, and so o.

4. A fairly complex unit test to test (3) failing, one that can't be
simplified as then the bug doesnt surface.

5. someone (me) trying to step through it. It takes about 30 minutes
to step through the test case, and if I go too far, I have to restart.

My life would be much easier if I override the toString() operation on
the element so that I can see what is going on inside without looking
in to every object. Yet in Element it is final.

Given that it is the Java convention that Object.toString() is there,
and it aint final, I would argue that making Element.toString() final
does not add much, but it takes away the ability of people like me to
override behaviour.

-steve