commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: clirr for MATH-389
Date Thu, 22 Jul 2010 21:49:05 GMT
Le 22/07/2010 23:35, Gilles Sadowski a écrit :
>>>> No, it was intentional so users can explicitly refer to it when building
>>>> the instance.
>>> 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.

> How useful is a default value anyway?
>>>>> Last 3 items: The field still exists but in a superclass. The problem
>>>>> 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 ?

>>>>> 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 tried to see whether similar changes where present between 2.0 an 2.1
>>>>> "mvn install" doesn't work on the source tree located at:
>>>>> [I've attached the console output.]
>>>> It seems you have some network outage now, because the file is really
>>>> there and accessible. Try it several times or check your proxy setting.
>>> There is no proxy. I run the same command ("mvn install") inside three
>>> directories:
>>>   MATH_2_0
>>>   MATH_2_1
>>>   trunk
>>> In the first it fails, in the last two it works.
>> I don't understand what happens.
> 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


> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message