On 1 May 2014 15:13, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 05/01/2014 03:39 PM, 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. > > As long as there was only 1 guy requesting this, I had the same opinion > as you (and I already wanted to close the issue as Wont fix). > > But who knows how many people/projects have done the same and now want > to migrate to collections 4 and are facing this issue.
Then perhaps we need to provide more documentation on why this change was made. > If there is too much trouble upgrading to collections 4, they might also > switch to guava, which I have seen a couple of times already. If Guava suits them better, so be it. > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
