xom-interest AT lists.ibiblio.org
Subject: XOM API for Processing XML with Java
List archive
Re: [XOM-interest] why is Element.toString() final?
- From: Noam Tamim <noamtm AT gmail.com>
- To: Steve Loughran <steve.loughran AT gmail.com>
- Cc: xom-interest <xom-interest AT lists.ibiblio.org>
- Subject: Re: [XOM-interest] why is Element.toString() final?
- Date: Wed, 21 Dec 2005 18:28:07 +0200
How about this plan:
1. Get the XOM source;
2. Remove the final;
3. Build XOM;
4. Add something that overrides Element.toString();
5. Debug.
When you found the bug, go back to the official XOM build, and make sure
your test passes.
Noam.
On 12/9/05, Steve Loughran <steve.loughran AT gmail.com> wrote:
>
> 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
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
>
-
[XOM-interest] why is Element.toString() final?,
Steve Loughran, 12/09/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Elliotte Harold, 12/09/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Steve Loughran, 12/09/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Noam Tamim, 12/21/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Steve Loughran, 12/21/2005
- Re: [XOM-interest] why is Element.toString() final?, Noam Tamim, 12/24/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Steve Loughran, 12/21/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Noam Tamim, 12/21/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Steve Loughran, 12/09/2005
-
Re: [XOM-interest] why is Element.toString() final?,
Elliotte Harold, 12/09/2005
Archive powered by MHonArc 2.6.24.