Le 24/07/2010 04:41, Bill Barker a écrit : > > > -------------------------------------------------- > From: "Phil Steitz" <phil.ste...@gmail.com> > Sent: Friday, July 23, 2010 5:42 PM > To: "Commons Developers List" <dev@commons.apache.org> > Subject: Re: clirr for MATH-389 > >> 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. >> > > +1 on creating a 2.2 branch and concentrating [math] on 3.0.
I would really much like to have a new version out this year, I need some changes for Orekit, and especially a new implementation of ODE with Jacobians (see discussion in MATH-380). So if going to 3.0 delays a new version, I would be against it. Luc > >> >> 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 >> > > --------------------------------------------------------------------- > 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
