commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [lang][collections] Utils having a public constructor
Date Tue, 13 Aug 2002 20:12:09 GMT
I would vote for public. Sort of 'be liberal in what you accept'. 
If it helps velocity - it may also help others, and it doesn't hurt others 
too much.

In the cases where a singleton is actually required we should of 
course use private constructor - but this is not the case in any of the 
utils I've seen. So if singleton is not required, why enforce it, 
especially when some projects are affected ?


On Tue, 13 Aug 2002, Henri Yandell wrote:

> > > > Yes, that would work.  However, it would break compatibility for
> > > > anyone already using StringUtils.
> > >
> > > But StringUtils hasn't been released yet.  It's in beta, yes?
> > > And the beta version had a private constructor. ?
> >
> > Portions of the code frrom StringUtils came from the Turbine project
> > (and possibly JServ before that), and has been in production use for
> > years.
> To be fair, StringUtils has changed a lot and anyone dependent on the old
> turbine code would most likely have made themselves known a while back.
> Methods were renamed, or thrown away due to not being generic enough.
> The private() was a pretty new addition a month or so prior to going beta,
> so I don't think anyone will be hurt by the private() being loosened. As
> to anyone who was being hurt by the introduction of the private(), I think
> Velocity style users would be the only one and Maven is the only one to
> have stood up so far.
> Lastly, this is not a StringUtils issue but a Commons.XXxxUtils issue. The
> current public() is there as a favour to Jason, but I'm anxious that a
> general Commons decision is made that we can all adhere to.
> Do we do public() as it's easy for Velocity/other-tools, and we assume our
> consumers can figure out that instantiating a class with only static
> methods is a bit thick.
> Do we do private() and tell Velocity to get its act together and stop
> using a loophole. The fact that Collections/Array have private() makes
> this a fine stance to take I'd have thought, unless Velocity only cares
> about String-based utilities.
> Do we do protected() and have some kind of back-door system in which
> people who need to use a Utils as an instance can extend it and use it
> that way [or do we provide an extended instance somehow?] and most
> consumers never know that the extension is not possible.
> Getting a decision on that is needed, StringUtils itself will just follow
> suit. The backwards compatibility only affects people if they have
> released a XxxUtils with a public constructor??
> Hen
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message