Luc Maisonobe wrote:
Le 24/07/2010 04:41, Bill Barker a écrit :
--
From: Phil Steitz phil.ste...@gmail.com
Sent: Friday, July 23, 2010 5:42 PM
To: Commons Developers List dev@commons.apache.org
Subject: Re: clirr for MATH-389
Gilles Sadowski
@commons.apache.org
Subject: Re: clirr for MATH-389
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
Le 24/07/2010 04:41, Bill Barker a écrit :
--
From: Phil Steitz phil.ste...@gmail.com
Sent: Friday, July 23, 2010 5:42 PM
To: Commons Developers List dev@commons.apache.org
Subject: Re: clirr for MATH-389
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
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
--
From: Phil Steitz phil.ste...@gmail.com
Sent: Friday, July 23, 2010 5:42 PM
To: Commons Developers List dev@commons.apache.org
Subject: Re: clirr for MATH-389
Gilles Sadowski wrote:
Intentional but still a mistake IMO ;-) as it's part
Hi.
Luc Maisonobe commented on MATH-389:
At first sight, it seems good to me.
You can check there are incomatibilities by performing the changes locally
and run clirr (for example by running mvn site) and check the clirr
report.
Here is the report
Le 22/07/2010 12:46, Gilles Sadowski a écrit :
Hi.
Luc Maisonobe commented on MATH-389:
At first sight, it seems good to me.
You can check there are incomatibilities by performing the changes locally
and run clirr (for example by running mvn site) and
On 22 July 2010 13:11, Luc Maisonobe luc.maison...@free.fr wrote:
Le 22/07/2010 12:46, Gilles Sadowski a écrit :
Hi.
Luc Maisonobe commented on MATH-389:
At first sight, it seems good to me.
You can check there are incomatibilities by performing the
Concerning the items related to this issue:
3rd item: The method is declared in a superclass.
4th item: The constant is defined in a superclass. It is still public but
I think that it's a mistake and should be made private instead.
No, it was intentional so users can explicitly refer
Le 22/07/2010 17:08, Gilles Sadowski a écrit :
Concerning the items related to this issue:
3rd item: The method is declared in a superclass.
4th item: The constant is defined in a superclass. It is still public but
I think that it's a mistake and should be made private instead.
No, it was
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
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
13 matches
Mail list logo
