commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <>
Subject Re: [VOTE] (re-vote) XxxUtils constructors
Date Wed, 21 Aug 2002 17:23:24 GMT
On Wednesday 21 August 2002 05:55 am, wrote:
> >  from:    Daniel Rall <>
> >  date:    Wed, 21 Aug 2002 09:19:55
> >  to:
> >  subject: Re: [VOTE] (re-vote) XxxUtils constructors
> >
> > Steve Downey <> writes:
> > > This is library code, and should be biased towards making unexpected
> > > uses possible. If someone extends StringUtils by subclassing, and
> > > version 2.0 comes out that adds new API, well, that's their lookout.
> >
> > My feelings exactly.  There is not a single reason I can think of, nor
> > one voiced so far, which should make us prevent people from having the
> > ability to do this.
> If you follow this thought process then every method ever written in an OSS
> project should be public.
> The privateers believe in the mantra of keep as much private as possible.
> However, they have also pretty much accepted that a use case exists for a
> public constructor. The final is there to keep the minimal exposure.

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.

> I would suggest that the privateers are offering a good compromise in
> public final. A request to the publiceers, would you at least consider
> compromising?

public final means you can't extend the class. Why MUST StringUtils NOT be 

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.

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

View raw message