-1 I agree with sebb. There is no use case for this. I've elaborated this
some more in the jira.


2014-05-01 20:18 GMT+02:00 Dipanjan Laha <dipanja...@gmail.com>:

> -1
>
> Imho this usecase also gives a false impression of over riding, so maybe we
> should make the util classes final as Gary suggested. And imo switching to
> Guava would be much more of an effort than to compose ones own util class
> :)
>
> On Thursday, 1 May 2014, Jörg Schaible
> <joerg.schai...@gmx.de<javascript:_e(%7B%7D,'cvml','joerg.schai...@gmx.de
> ');>>
> wrote:
>
> > sebb wrote:
> >
> > > On 1 May 2014 14:21, Thomas Neidhart <thomas.neidh...@gmail.com>
> wrote:
> > >> On 05/01/2014 03:03 PM, sebb wrote:
> > >>> On 1 May 2014 12:05,  <t...@apache.org> wrote:
> > >>>> Author: tn
> > >>>> Date: Thu May  1 11:04:59 2014
> > >>>> New Revision: 1591602
> > >>>>
> > >>>> URL: http://svn.apache.org/r1591602
> > >>>> Log:
> > >>>> [COLLECTIONS-519] Constructors of *Utils classes are now protected
> to
> > >>>> [allow sub-classing. Thanks to Radoslav Paskalev, Daniel Feist.
> > >>>
> > >>> -1
> > >>>
> > >>> I don't think this is a good idea.
> > >>>
> > >>> See my comments on the JIRA issue.
> > >>
> > >> I consider this to be a compromise considering the fact that
> previously
> > >> the util classes all had a public constructor.
> > >>
> > >> So when people are migrating from 3.2.1 to 4.0, they have some
> troubles.
> > >> To ease the migration I thought that making it protected is safe:
> > >>
> > >>  * it can not be instantiated
> > >
> > > Surely it is now instantiable via a sub-class?
> > >
> > >>  * if somebody wants to sub-class: at your own risk, like before
> > >>
> > >> The composition approach is the right way to go, and I would
> personally
> > >> never do something like the issue originator.
> > >
> > > The problem we have is that if 4.1 now allows sub-classing, how can we
> > > ever drop it?
> > >
> > > We need to grab the opportunity of 4.x to fix all these bad coding
> > > practises.
> > >
> > > Conversion to 4.x will amyway require some effort on the part of users.
> > > Let's not spoil the API for all for the sake of a few.
> >
> > +1
> >
> > We broke the API on purpose.
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Reply via email to