commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Downey" <steve.dow...@netfolio.com>
Subject RE: [VOTE] (3b) XxxUtilsConstructors last chance
Date Fri, 23 Aug 2002 16:01:02 GMT
I think the inner class solution is better than the wrapper. Zero
maintenance. Although I think having an inner class that exists solely to
provide a public constructor that the outer doesn't provide is silly.

The inner class and wrapper have all of the disadvantages marshaled against
having a public constructor in StringUtils. Why not just have the public
constructor, rather than a work around that provides almost the same thing?

Deprecating the public constructor, with a note explaining that you probably
don't need to use it, is, I think, a good solution. Deprecating it will warn
naive users, while still allowing those who actually need it to use it. But
it isn't deprecated because it's planned to be removed, or because those who
need it should move to a different API. It's deprecated because it should
only be used in very particular, somewhat unusual, circumstances.

This would be analogous to Thread.stop(). It's not safe, for a whole lot of
reasons. Nonetheless, it can't be removed. Not because of backwards
compatibility, but because there sometimes isn't any other way of doing the
job. Sometimes you need to kill an unresponsive thread. It's better to use
thread.interrupt(), and let the task clean itself up gracefully, but what do
you do when the task ignores the request, shut down the whole VM?

> -----Original Message-----
> From: Steven Caswell [mailto:steven@caswell.name]
> Sent: Friday, August 23, 2002 9:19 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [VOTE] (3b) XxxUtilsConstructors last chance
>
>
> Sorry this response is late, but I have trouble sending e-mail at work.
> Yes, in a previous posting I said I would have no problem maintaining
> the wrapper.
>
>
> Steven Caswell
> steven@caswell.name
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
>
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> > Sent: Thursday, August 22, 2002 8:02 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [VOTE] (3b) XxxUtilsConstructors last chance
> >
> >
> > On 8/21/02 7:38 PM, "Steven Caswell" <steven@caswell.name> wrote:
> >
> > > My vote is -0 instead of +0 because I haven't heard anyone
> > present a
> > > serious reason as to why a utility class, a non-bean, should be
> > > subject to subclassing.
> >
> > I can only assume you're joking.  Maybe someone wants to
> > change the behavior?
> >
> >
> > > I can somewhat see the need for construction for tools
> > > that require a bean (which a utility class really isn't),
> > but I think
> > > other compromises, such as a wrapper class, would also be
> > reasonable.
> >
> > Do you want to maintain that wrapper class?
> >
> >
> > --
> > Geir Magnusson Jr.
> > Research & Development, Adeptra Inc.
> > geirm@adeptra.com
> > +1-203-247-1713
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message