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 (nike.apache.org: local policy)
Date: Thu, 22 Jul 2010 23:35:17 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: clirr for MATH-389
Message-ID: <20100722213517.GU28835@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C48AB4F.9000702@free.fr>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: hel 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Checked: Checked by ClamAV on apache.org

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

> >>> 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?


> >>> I tried to see whether similar changes where present between 2.0 an 2.1 but
> >>> "mvn install" doesn't work on the source tree located at:
> >>>   http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0
> >>> [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?

Gilles

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