2011/1/2 Phil Steitz <phil.ste...@gmail.com>: > On Sun, Jan 2, 2011 at 1:42 PM, Mikkel Meyer Andersen <m...@mikl.dk> wrote: > >> Hi, >> >> In general: I understand that removing e.g. functions to an interface >> is (seriously) breaking compatibility. Why is it just as bad to add >> e.g. functions to an interface? As far as I know, the binaries are >> still compatible, so where does this "adding breaks compatibility" >> stem from? And is it only in interfaces and abstract classes, or is it >> also in implementing classes (such as implemented probability >> distributions)? Sorry if these are stupid questions or stuff I ought >> to know. >> > > Adding to implementation classes is not a problem. Adding methods to > interfaces or abstract methods to abstract classes forces all > implementations of the interfaces / subclasses of the abstract class to > implement the methods. So if, for example, someone has implemented their > own normal distribution class following the 2.1 interface and deriving from > the 2.1 base class, their code will break in 2.2 since it is missing the new > methods. The current code effective forces all distribution implementations > to support the new features. Removing the new stuff from the interfaces > (and the one new abstract method) will allow any "old" distributions > implemented by users to continue to work in 2.2, while adding the new > functionality to the [math]-supplied distributions. Of course. Thanks for spelling it out. -Cheers, Mikkel. > > Phil > >> >> 2011/1/2 Phil Steitz <phil.ste...@gmail.com>: >> > The clirr report run from the current MATH_2_X branch is, as expected, >> > problematic. To get 2.2. out, we need to agree on what breaks we are >> going >> > to allow and what we are going to fix. Here is a first cut and proposal >> > for some immediate fixes that I would appreciate feedback on. >> > >> > 0) The improvements to the distributions classes to add characteristic >> > support and positive mass domains have added some new methods to >> interfaces >> > and new abstract methods to abstract classes. I apologize for not >> spotting >> > this in initial patch reviews or being clear in discussion of the >> > features. I think we can keep the functionality without introducing the >> > compatibility breaks by removing the added methods from interfaces / >> > abstract classes. The only painful part is the nice solution for caching >> > numerical characteristics that will have to be repeated in the >> > implementation classes that need it. I would like to proceed with these >> > changes in the 2.2 branch if others are OK with it. >> +1 >> I'll also apologize for not realising my solution broke compatibility. >> I'm okay with your workaround, if we are not just pushing the >> functionality to 3.0? >> > >> >> 1) Removed superclasses in the exception hierarchy. I am OK leaving these >> > as is. >> +1 >> > >> > I don't know what, if anything, to do about the following: >> Me neither. If they are truly incompatible, are the only options then >> to either break compatibility or push to 3.0? >> > >> > 2) Changed return type of interpolate in BicubicSpline. >> > >> > 3) Incompatible changes in the ode package. >> > >> > 4) Incompatible changes in the optimization package. >> > >> > Thanks in advance! >> > >> > Phil >> > >> >> Cheers, Mikkel. >> >> --------------------------------------------------------------------- >> 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
