commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: clirr for MATH-389
Date Thu, 22 Jul 2010 21:35:17 GMT
> >> 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
> >>> "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?


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

View raw message