> >> 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
