> >>> 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.
Unless I'm mistaken, the meaning of "iteration" is algorithm-dependent, and the "maximum" will depend on the problem and the requested accuracy, so how could CM know what is a "good" default? As far as I can tell, the value (100) was picked out of thin air. For the number of evaluations, the default is MAX_VALUE (which makes more sense, in some sense ;-); and note that this one is not defined as a public static variable! Certainly, the (graphical interface) program has more information (which problem it is solving and which optimization algorithm it is going to call to do so) to make the right default choice. In summary, this variable pollutes the CM API for no reason. > > 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 ? I've deprecated them. > >>>>> 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've already suggested that we should try and assess the real impact of the changes so that we can compare the drawbacks of each approach. I.e. how many people/projects are out there that would really be annoyed by a recompilation at each dot release. > > [...] > > > > 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. But I was interested in seeing if similarly incompatible changes were introduced in 2.1 (hence I need to "mvn install" 2.0). Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
