Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 74.125.82.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=RWfvVcihuYAAAfPPuuUs5qIrMkVzwtxWB7obac4vhAumYVwuQSa1IQ7kewFnlwbVwI
         asxb4l8xIm/sRlitv1AJHf/hhYJVDRV8DPJQFPmtaxTLvOS/iz/ouAUBwMV8wPHcrX8l
         ZXCH9JTgrh+6d1URBV9y1heSxLf1Ov6e0boU0=
MIME-Version: 1.0
In-Reply-To: <20101202004205.GB16182@dusk.harfang.homelinux.org>
References: <4CF68533.50003@free.fr>
 <20101201193119.GK10411@dusk.harfang.homelinux.org>
 <4CF6B76B.6090001@free.fr>
 <20101202004205.GB16182@dusk.harfang.homelinux.org>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Thu, 2 Dec 2010 00:41:52 -0800
Message-ID: <AANLkTim_1ezyn3nnqcUEdZZWtgYCmPac7=hic3WL5+Px@mail.gmail.com>
Subject: Re: [math] max evaluations in new root solvers
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=e0cb4e3853da05af030496696683

--e0cb4e3853da05af030496696683
Content-Type: text/plain; charset=UTF-8

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

--e0cb4e3853da05af030496696683--