commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] max evaluations in new root solvers
Date Thu, 02 Dec 2010 19:17:21 GMT
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 <
> gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message