Gilles Sadowski wrote: >>>>> 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.
We should adhere to Commons standards. The standards are clear: http://commons.apache.org/releases/versioning.html Clirr ERRORs generally call out standards exceptions for a .x release. I have no problem using natural numbers more quickly. We have plenty! Why not just start working 3.0 in trunk. We can create a 2.x branch so we can cut a 2.2 if some really bad bugs show up before we get 3.0 out. We all agree that the [math] API needs work. If we cut more frequent major releases, we can evolve the API. Lets do that. Phil >>> [...] >>> >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
