commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [VOTE] (re-vote) XxxUtils constructors
Date Wed, 21 Aug 2002 19:35:49 GMT
> Private is a good default for application code. For reuseable 
> library code, private is not a good choice. Object libraries 
> should be extensible. Private and final make extension difficult 
> or impossible. Protected should be used.  Protected means that 
> applications can't accidentally break the object by using the 
> method in an inappropriate way. But it leaves the door open for 
> someone to subclass it when they feel they need to. 
> Trust the developers. And if they screw up, it's their problem.

What if you're the one who screwed up?  By exposing the 
implementation details as protected you've greatly limited the
things you can do to fix bugs.  You can't eliminate a protected
field because that breaks backward compatibility.  You can't
change the return type of a protected method because that 
breaks backward compatibility.  And so on.

> public final means you can't extend the class. Why MUST 
> StringUtils NOT be extended? 
> There was a straw man argument that someone might extend 
> StringUtils, and that later versions of StringUtils might want 
> to use those signatures, or ones that prevent the extended StringUtils
> (eg Parser) from compiling. I'll conceed that one. StringUtils owns 
> it's interface. If it adds parse() in v 2, then all clients that have 
> extended it will have to change their classes.

But that's clearly not how this process is working, now is it?
That's not what we'd hear at all.  What we'd hear is, "TomCat uses
Parsers in fifteen different places!  We don't want to change them
all" OR "TomCat exposes a Parser in its public API that users use
to extend TomCat, so we can't change without breaking compatibility"
OR "TomCat's more important than commons".

Really, it's horrible horrible agony.

Static methods can't be overridden, and are always visible from 
anywhere.  Why MUST StringUtils BE extended?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message