Le 02/12/2010 09:41, Ted Dunning a écrit : > I think that the suggestion is to preserve the old signatures in 3.0, but > have them not only be deprecated but also throw an error. This is an > incompatible change that can't really be done in a point release. Simply > removing the old signatures makes it harder to track down the problem. > Preserving the old signatures for error trapping only allows precise error > feedback of the form "We told you not to do this in 2.2, now we mean it!".
This is not what I had in mind, but it's better! Luc > > I think that that suggestion to preserve the old signature for error > trapping is an excellent one. It doesn't need to be done forever and > removing the error throwing variants needn't be considered an API change. > > On Wed, Dec 1, 2010 at 4:42 PM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > >>>> In order to avoid nasty surprises, what about having these "old" >>>> constructors deprecated and throw a "MathUnsupportedOperationException" >> in >>>> 3.0 and remove them in 3.x? [This is an incompatible change but the >>>> exception throwing will make it sure that nobody can actually depend on >> this >>>> constructor.] >>> >>> No, we can deprecate them as early as 2.2 and remove them in 3.0, just >>> as the other changes we already did. >> >> But... in 2.2, the new code (contructors with 2 tolerances as parameters) >> does not exist, and in 3.0, the old code (constructor with a >> "maxIterations" >> and tolerance parameters) does not exist. >> So indeed, this former constructor should be deprecated (in 2.2) but there >> is nothing to remove (in 3.0). And still, code that uses the old interface >> with the new library will fail, as you described. [Or I didn't understand >> what the problem is, or the proposed solution...] > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
