- "Phil Steitz" a écrit :
> Luc Maisonobe wrote:
> > Le 24/07/2010 04:41, Bill Barker a écrit :
> >>
> >> --
> >> From: "Phil Steitz"
> >> Sent: Friday, July 23, 2010 5:42 P
Luc Maisonobe wrote:
> Le 24/07/2010 04:41, Bill Barker a écrit :
>>
>> --
>> From: "Phil Steitz"
>> Sent: Friday, July 23, 2010 5:42 PM
>> To: "Commons Developers List"
>> S
Le 24/07/2010 04:41, Bill Barker a écrit :
>
>
> --
> From: "Phil Steitz"
> Sent: Friday, July 23, 2010 5:42 PM
> To: "Commons Developers List"
> Subject: Re: clirr for MATH-389
>
>> Gilles Sadow
--
From: "Phil Steitz"
Sent: Friday, July 23, 2010 5:42 PM
To: "Commons Developers List"
Subject: Re: clirr for MATH-389
Gilles Sadowski wrote:
Intentional but still a mistake IMO ;-) as it's part of the interface
wh
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 obta
> >>> 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
> >>> va
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
> >> 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
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" inste
> > 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 e
On 22 July 2010 13:11, Luc Maisonobe 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 chang
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 runnin
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 th
13 matches
Mail list logo
