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 phil.steitz@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=Pq5VVyhCCdcNnS4HJmSaYV+4dbJ6BAFs4dGVp96CnJ1meIfyYuuk33LTK62tvdzKd9
         THBibT21TeJWp22Sgpee1G4S6tJx3F6MLj4X6ipMXGTsR3e8XRevhTmnThnaTD+I67k7
         XDn2brxtoagoME8y1zsM6FjtF0aquZHkvocFI=
Message-ID: <4C4A3708.7080301@gmail.com>
Date: Fri, 23 Jul 2010 20:42:48 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: clirr for MATH-389
References: <3615837.472241279617349797.JavaMail.jira@thor>
 <2166498.479701279648672166.JavaMail.jira@thor>
 <20100722104606.GS28835@dusk.harfang.homelinux.org>
 <4C483568.6050304@free.fr>
 <20100722150845.GT28835@dusk.harfang.homelinux.org>
 <4C48AB4F.9000702@free.fr>
 <20100722213517.GU28835@dusk.harfang.homelinux.org>
 <4C48BCD1.2060001@free.fr> <20100723224748.GK6681@dusk.harfang.homelinux.org>
In-Reply-To: <20100723224748.GK6681@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gilles Sadowski wrote:
>>>>> Intentional but still a mistake IMO ;-) as it's part of the interface
>>>>> whereas the prime use is to allow to define a default constructor so that
>>>>> the user does *not* have to refer to the value.
>>>>> When using the default constructor, the user can always obtain the default
>>>>> value with "getMaxIterations()".
>>>> No, the user can get this value only once the instance has already been
>>>> built, not before calling the constructor.
>>> Of course. I didn't say otherwise.
>>> When does the user need to know this value before calling the constructor?
>> Mainly displaying it in a graphical user interface, as an hint for the
>> user to choose either this default or something else if he want to.
> 
> Unless I'm mistaken, the meaning of "iteration" is algorithm-dependent, and
> the "maximum" will depend on the problem and the requested accuracy, so how
> could CM know what is a "good" default? As far as I can tell, the value
> (100) was picked out of thin air. For the number of evaluations, the default
> is MAX_VALUE (which makes more sense, in some sense ;-); and note that this
> one is not defined as a public static variable!
> 
> Certainly, the (graphical interface) program has more information (which
> problem it is solving and which optimization algorithm it is going to call
> to do so) to make the right default choice.
> 
> In summary, this variable pollutes the CM API for no reason.
> 
>>> How useful is a default value anyway?
>>>
>>>>>>> Last 3 items: The field still exists but in a superclass. The problem would
>>>>>>> have been prevented if those fields were "private" instead of "protected".
>>>>> I suggest that access to those fields is also changed to "private" (this
>>>>> breaks compatibility just the same) and I'll add accessors to be used by
>>>>> derived classes for accessing them. OK?
>>>> I'm on the fence on this.
>>> What can you do with a "protected" field that you can't with the object
>>> returned by an accessor?
>>> [I even think that we should go towards immutability for those fields...]
>> Yes, of course, but when I say I'm on the fence it is rather because it
>> introduces another incompatibility. How about deprecating them for now
>> and changing them to private (and perhaps final) in 3.0 ?
> 
> I've deprecated them.
> 
>>>>>>> So, what does that mean with respect to committing the changes into the
>>>>>>> trunk?
>>>>>> There does not seem to be any major problem, so you can commit your changes.
>>>>> Wow, that's unexpected good news. It's a relief that backward compatibility
>>>>> isn't that stringent a requirement :-)
>>>> It is a stringent requirement. But it seemed to me that the changes were
>>>> not that important.
>>> Fine then. I don't think they are but...
>>>
>>>> Did I miss something ?
>>> ... How would I know? Is there a policy that "clirr" cannot report "ERROR"?
>>> If not, then how do you decide what is important and what isn't?
>> It is a matter of feeling and experience. It is highly subjective and
>> this discussion is a perfect example of this. We can see you are ready
>> to change almost anything anytime, Phil doesn't want some changes to be
>> introduced at dot releases, and I am somewhere in between.
>>
>> We are a community, and it is important we exchange our views here.
> 
> I've already suggested that we should try and assess the real impact of
> the changes so that we can compare the drawbacks of each approach. I.e. how
> many people/projects are out there that would really be annoyed by a
> recompilation at each dot release.

We should adhere to Commons standards. The standards are clear:
http://commons.apache.org/releases/versioning.html

Clirr ERRORs generally call out standards exceptions for a .x release.

I have no problem using natural numbers more quickly. We have
plenty! Why not just start working 3.0 in trunk.  We can create a
2.x branch so we can cut a 2.2 if some really bad bugs show up
before we get 3.0 out.

We all agree that the [math] API needs work. If we cut more frequent
major releases, we can evolve the API.  Lets do that.


Phil


>>> [...]
>>>
>>> Maybe that the "MATH_2_0" branch contains outdated things...
>>> Does it work on your machine?
>> I didn't try. However, I'm not sure clirr is useful on a major release
>> as it is at these releases that we allow ourselves to introduce great
>> changes.
> 
> But I was interested in seeing if similarly incompatible changes were
> introduced in 2.1 (hence I need to "mvn install" 2.0).
> 
> 
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org