commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: [math] max evaluations in new root solvers
Date Thu, 02 Dec 2010 08:41:52 GMT
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!".

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 <> 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...]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message