commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 2.2 compatibility issues
Date Sun, 02 Jan 2011 19:07:05 GMT
On Sun, Jan 2, 2011 at 1:42 PM, Mikkel Meyer Andersen <mikl@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.

Phil

>
> 2011/1/2 Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message