commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikkel Meyer Andersen <m...@mikl.dk>
Subject Re: [math] 2.2 compatibility issues
Date Sun, 02 Jan 2011 19:12:30 GMT
2011/1/2 Phil Steitz <phil.steitz@gmail.com>:
> 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.
Of course. Thanks for spelling it out. -Cheers, Mikkel.
>
> 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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message