[math] incompatible change in r936295

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[math] incompatible change in r936295

Phil Steitz
Sorry I did not notice this before.  I see it now flagged by the
Clirr report.  The problem is here:

-    public BivariateRealFunction interpolate(final double[] xval,
-                                             final double[] yval,
-                                             final double[][] zval)
+    public BicubicSplineInterpolatingFunction interpolate(final

Changing the return type of a function is an incompatible change.
We should revert this change.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Julius Davies
On Mon, May 31, 2010 at 5:36 PM, Phil Steitz <[hidden email]> wrote:

> Sorry I did not notice this before.  I see it now flagged by the
> Clirr report.  The problem is here:
>
> -    public BivariateRealFunction interpolate(final double[] xval,
> -                                             final double[] yval,
> -                                             final double[][] zval)
> +    public BicubicSplineInterpolatingFunction interpolate(final
>
> Changing the return type of a function is an incompatible change.
> We should revert this change.
>

Even though BicubicSplineInterpolatingFunction implements
BivariateRealFunction ?


> Phil
>


--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Gilles Sadowski

> > Sorry I did not notice this before.  I see it now flagged by the
> > Clirr report.  The problem is here:
> >
> > -    public BivariateRealFunction interpolate(final double[] xval,
> > -                                             final double[] yval,
> > -                                             final double[][] zval)
> > +    public BicubicSplineInterpolatingFunction interpolate(final
> >
> > Changing the return type of a function is an incompatible change.
> > We should revert this change.
> >
>
> Even though BicubicSplineInterpolatingFunction implements
> BivariateRealFunction ?

Hence, this is not an incompatible change.

Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Phil Steitz
Gilles Sadowski wrote:

>>> Sorry I did not notice this before.  I see it now flagged by the
>>> Clirr report.  The problem is here:
>>>
>>> -    public BivariateRealFunction interpolate(final double[] xval,
>>> -                                             final double[] yval,
>>> -                                             final double[][] zval)
>>> +    public BicubicSplineInterpolatingFunction interpolate(final
>>>
>>> Changing the return type of a function is an incompatible change.
>>> We should revert this change.
>>>
>> Even though BicubicSplineInterpolatingFunction implements
>> BivariateRealFunction ?
>
> Hence, this is not an incompatible change.

Unfortunately, no.  See
http://commons.apache.org/releases/versioning.html
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
(13.4.15)
http://wiki.eclipse.org/Evolving_Java-based_APIs_2

Clients that recompile and just use the method will not break.
Clients that do not recompile and/or extend the class may break.

Phil
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Gilles Sadowski
> >>> Sorry I did not notice this before.  I see it now flagged by the
> >>> Clirr report.  The problem is here:
> >>>
> >>> -    public BivariateRealFunction interpolate(final double[] xval,
> >>> -                                             final double[] yval,
> >>> -                                             final double[][] zval)
> >>> +    public BicubicSplineInterpolatingFunction interpolate(final
> >>>
> >>> Changing the return type of a function is an incompatible change.
> >>> We should revert this change.
> >>>
> >> Even though BicubicSplineInterpolatingFunction implements
> >> BivariateRealFunction ?
> >
> > Hence, this is not an incompatible change.
>
> Unfortunately, no.  See
> http://commons.apache.org/releases/versioning.html
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
> (13.4.15)
> http://wiki.eclipse.org/Evolving_Java-based_APIs_2
>
> Clients that recompile and just use the method will not break.
> Clients that do not recompile and/or extend the class may break.


I don't understand.
Supposing that some (compiled) client code refers to

  BivariateRealFunction interpolate(...)

Since "BivariateRealFunction" is an interface, then, by definition, the
code cannot contain information about the specific type that will be
returned.
How can this code break when a "BicubicSplineInterpolatingFunction" is
returned?


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Julien Aymé
Hi,

Some compiled client code can break if it extends the method, and
returns something which is a BivariateRealFunction, but not a
BicubicSplineInterpolatingFunction.
Since the super class method contract has changed, the client code
does not respect the contract (return
BicubicSplineInterpolatingFunction) any longer.
Hence the break.

HTH,
Regards,

Julien

2010/6/1 Gilles Sadowski <[hidden email]>:

>> >>> Sorry I did not notice this before.  I see it now flagged by the
>> >>> Clirr report.  The problem is here:
>> >>>
>> >>> -    public BivariateRealFunction interpolate(final double[] xval,
>> >>> -                                             final double[] yval,
>> >>> -                                             final double[][] zval)
>> >>> +    public BicubicSplineInterpolatingFunction interpolate(final
>> >>>
>> >>> Changing the return type of a function is an incompatible change.
>> >>> We should revert this change.
>> >>>
>> >> Even though BicubicSplineInterpolatingFunction implements
>> >> BivariateRealFunction ?
>> >
>> > Hence, this is not an incompatible change.
>>
>> Unfortunately, no.  See
>> http://commons.apache.org/releases/versioning.html
>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
>> (13.4.15)
>> http://wiki.eclipse.org/Evolving_Java-based_APIs_2
>>
>> Clients that recompile and just use the method will not break.
>> Clients that do not recompile and/or extend the class may break.
>
>
> I don't understand.
> Supposing that some (compiled) client code refers to
>
>  BivariateRealFunction interpolate(...)
>
> Since "BivariateRealFunction" is an interface, then, by definition, the
> code cannot contain information about the specific type that will be
> returned.
> How can this code break when a "BicubicSplineInterpolatingFunction" is
> returned?
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

James Carman
In reply to this post by Gilles Sadowski
On Tue, Jun 1, 2010 at 8:37 AM, Gilles Sadowski
<[hidden email]> wrote:

> I don't understand.
> Supposing that some (compiled) client code refers to
>
>  BivariateRealFunction interpolate(...)
>
> Since "BivariateRealFunction" is an interface, then, by definition, the
> code cannot contain information about the specific type that will be
> returned.
> How can this code break when a "BicubicSplineInterpolatingFunction" is
> returned?

The "pointer" to the method is based on the return type.  If it
changes (even in a compatible way as far as recompiling is concerned),
it's not the same method.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Gilles Sadowski
In reply to this post by Julien Aymé
Hi.

> Some compiled client code can break if it extends the method, and
> returns something which is a BivariateRealFunction, but not a
> BicubicSplineInterpolatingFunction.
> Since the super class method contract has changed, the client code
> does not respect the contract (return
> BicubicSplineInterpolatingFunction) any longer.
> Hence the break.

Thanks for the explanation.

OK. So there is indeed an incompatible change between 2.1 and current (to
become 2.2). Is this really a problem? I mean, it could be seen as a bug
fix (i.e. it was a mistake to return the super-class type)!
Does the policy forbid such kind of fixes even if prevents the development
of CM code that depends on these fixes?

As I've already proposed for another compatibility breaking fix, can't we
set up a poll on the "user" ML in order to assess the *real* damage that
the modification will entail?


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Phil Steitz
Gilles Sadowski wrote:

> Hi.
>
>> Some compiled client code can break if it extends the method, and
>> returns something which is a BivariateRealFunction, but not a
>> BicubicSplineInterpolatingFunction.
>> Since the super class method contract has changed, the client code
>> does not respect the contract (return
>> BicubicSplineInterpolatingFunction) any longer.
>> Hence the break.
>
> Thanks for the explanation.
>
> OK. So there is indeed an incompatible change between 2.1 and current (to
> become 2.2). Is this really a problem? I mean, it could be seen as a bug
> fix (i.e. it was a mistake to return the super-class type)!
> Does the policy forbid such kind of fixes even if prevents the development
> of CM code that depends on these fixes?

What exactly does postponing this change prevent?  Why can't we just
cast the return if necessary?  The class itself is deprecated, to be
removed I assume in 3.0, so I don't see much risk in our casting
return types internally in the interim.  Am I missing something here?

>
> As I've already proposed for another compatibility breaking fix, can't we
> set up a poll on the "user" ML in order to assess the *real* damage that
> the modification will entail?

First, we can't count on the fact that all or impacted users are
subscribed to the user list.  Second, we have a policy that .x
releases should be drop-in replacements, which means they need to be
source and binary compatible.  Users who "drop in" a replacement
with a method signature change without recompiling all linked code
will get runtime exceptions when they invoke the changed method -
even if the change is "harmless" for them.  That was James' point.

We can certainly talk about changing the Commons versioning policy
to allow incompatible changes in .x releases; but until we agree to
do that, we need to do our best to comply.

Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] incompatible change in r936295

Gilles Sadowski

> > OK. So there is indeed an incompatible change between 2.1 and current (to
> > become 2.2). Is this really a problem? I mean, it could be seen as a bug
> > fix (i.e. it was a mistake to return the super-class type)!
> > Does the policy forbid such kind of fixes even if prevents the development
> > of CM code that depends on these fixes?
>
> What exactly does postponing this change prevent?  Why can't we just
> cast the return if necessary?  The class itself is deprecated, to be
> removed I assume in 3.0, so I don't see much risk in our casting
> return types internally in the interim.  Am I missing something here?

No; I was.  I thought that you were referring to a similar code in the
"BicubicSplineInterpolator" class!
The "SmoothingBicubicSplineInterpolator" can be reverted with no further
thought.

> [...]

Sorry for the noise,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]