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 *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?
Mainly displaying it in a graphical user interface, as an hint for the user to choose either this default or something else if he want to. > 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...] Yes, of course, but when I say I'm on the fence it is rather because it introduces another incompatibility. How about deprecating them for now and changing them to private (and perhaps final) in 3.0 ? > >>>>> 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? It is a matter of feeling and experience. It is highly subjective and this discussion is a perfect example of this. We can see you are ready to change almost anything anytime, Phil doesn't want some changes to be introduced at dot releases, and I am somewhere in between. We are a community, and it is important we exchange our views here. > > >>>>> 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? I didn't try. However, I'm not sure clirr is useful on a major release as it is at these releases that we allow ourselves to introduce great changes. Luc > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
