Luc Maisonobe wrote: > 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.
I understand. Can you have a look at the issues marked 2.1 and see if in your opinion any can be moved to 3.0? Then we can cut a 2.2 branch in which we unwind any incompatible changes from trunk and then allow ourselves more flexibility to fix API problems in trunk for 3.0. The downside of this approach is that we will have to apply patches to both branches for a while. I am OK with this and will help with the backporting and getting 2.2 out if others are amenable. Does this sound OK? Phil > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
