You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2010/11/16 21:52:04 UTC
[math] preparing smooth interface upgrade for users
Hello all,
As we are changing a lot of things in 3.0, it would be interesting to
have 2.2 help users smoothly adapt their code. Many exceptions have/will
be changed and some of them are used in public interfaces users have to
implement. Typical examples are FirstOrderDifferentialEquations and the
associated DerivativeException, or UnivariateRealFunction and
FunctionEvaluationException.
Discussion on MATH-425 lead to group these user-specific exception as
one single unchecked exception: MathUserException. This choice has the
additional advantage that when a user uses an ode solver inside an
optimizer for example, the same exception can be used at both levels and
an error condition occurring at very low level can be handled at top
level without problem.
In order to help users, I am going to use for 2.2 a transition scheme
where the exceptions DerivativeException, FunctionEvaluationException
and similar ones would all be deprecated and at the same time their base
class would be changed to the new MathUserException. Then the user
methods in the public interfaces would be declared to throw
MathUserException. So we would change from the current design which is:
public class DerivativeException extends MathException {...}
public interface FirstOrderDifferentialEquations {
public void computeDerivatives(...) throws DerivativeException;
}
to a new design which would be:
public class MathUserException extends RuntimeException {...}
@Deprecated
public class DerivativeException extends MathUserException {...}
public interface FirstOrderDifferentialEquations {
public void computeDerivatives(...) throws MathUserException;
}
Then in 3.0 the deprecated exceptions would be removed (I think Gilles
already did it).
This is an interface change, but I think it is worth doing it and it
does provide a sufficient level of compatibility. These interfaces are
intended to be implemented by user, to implement their own business
problems. Many already have implemented the interface in its 2.1
version, probably using a DerivativeException for their error handling.
Since DerivativeException would still be there in 2.2 and it would
extend MathUserException, these implementations would both continue to
work in 2.2 and new users and new implementations could already use the
new MathUSerExceptions. The only pain for existing implementations would
be to see warnings about the deprecated exceptions. Users would have
some time to adapt their code and use directly MathUserException, which
provide at least everything DerivativeException did provide up to now.
I guess CLIRR will complain and consider this an incompatible change. It
is true from a caller perspective since now we should expect
MathUserExceptions rather than only DerivativeExceptions. However,
MathUSerException is unchecked and the callers for these interfaces are
the commons-math methods, which we will adapt. These interfaces are not
intened to be called by user code, they are intended so that user code
can be called by our library.
I think this transition is the smoother path for our users. Do you think
this change is the way to go ?
best regards,
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > [...]
>
> I think what Luc is suggesting is that by introducing
> MathUserException in 2.2 without a material compatibility break
> (i.e. nothing that would actually break any 2.1 code) we could set
> users to start doing this work incrementally before 3.0 is released.
> That seems like a good idea to me IIUC what the impacts are.
Exceptions that are checked in 2.1 (e.g. "FunctionEvaluationException",
"DerivativeException", ...) would become unchecked in 2.2, as they'll
inherit from "MathUserException".
Isn't that a compatibility break?
> >>>In 3.0 it will clear that they *have* to do it while, in 2.2, you would
> >>>have to explain to users that it's better that they do it but that it
> >>>will still work if they don't... And they will probably say: "If it ain't
> >>>broken, I won't fix it." ;-)
> >>
> >>However, deprecation warnings are a strong hint that failure is
> >>imminent, and they may wish to prepare for the change.
> >
> >Yes. We should advertise the list of exceptions that are going to be
> >replaced by "MathUserException" when users switch 3.0, by deprecating
> >them in 2.2.
> >The preparation is to have a perl (or sed or ...) script ready.
> >
> I think we all agree on the deprecations. I understand your view,
> Gilles, that Luc's suggestion does not reduce work for those
> upgrading to 3.0; but don't you agree it would be helpful for them
> to be able to start - even just with new code they are developing -
> using the new user exception, assuming we can introduce it in 2.2
> without breaking anything?
>
> Luc / Sebb - can you see any real backward compat issue? Would this
> change force a recompile?
Where, in 2.1, the compiler would have enforced "throws" clauses or
catching the checked exceptions, a recompilation would not.
And, still, the binaries would be compatible?
If that's the case, and you all think that that way is an easier upgrade
path, I really don't mind.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by Phil Steitz <ph...@gmail.com>.
On Nov 19, 2010, at 9:50 AM, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 19/11/2010 16:39, Phil Steitz a écrit :
>> On 11/19/10 8:52 AM, Luc Maisonobe wrote:
>>> Le 17/11/2010 21:08, sebb a écrit :
>>>> On 17 November 2010 19:53, Luc Maisonobe<Lu...@free.fr> wrote:
>>>>> Le 17/11/2010 13:48, Phil Steitz a écrit :
>>>>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>>>>>> [...]
>>>>>>>>>> I think this transition is the smoother path for our users. Do you
>>>>>>>>>> think
>>>>>>>>>> this change is the way to go ?
>>>>>>>>>
>>>>>>>>> -0
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>>
>>>>>>>>> My first impression is that it is a lot of changes for 2.2
>>>>>>>>> without any
>>>>>>>>> benefit when users will switch to 3.0; they will still have to scan
>>>>>>>>> their
>>>>>>>>> code for all the exceptions that will have disappeared.
>>>>>>>>
>>>>>>>> Won't the deprecations take care of that?
>>>>>>>
>>>>>>> I didn't mean that they have to scan "manually", just that they will
>>>>>>> have to
>>>>>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>>>>>> work).
>>>>>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>>>>>> rule in
>>>>>>> 2.2.
>>>>>>
>>>>>> I think what Luc is suggesting is that by introducing
>>>>>> MathUserException
>>>>>> in 2.2 without a material compatibility break (i.e. nothing that would
>>>>>> actually break any 2.1 code) we could set users to start doing this
>>>>>> work
>>>>>> incrementally before 3.0 is released. That seems like a good idea
>>>>>> to me
>>>>>> IIUC what the impacts are.
>>>>>
>>>>> You are right, this is exactly what I try to do.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2,
>>>>>>>>> you would
>>>>>>>>> have to explain to users that it's better that they do it but
>>>>>>>>> that it
>>>>>>>>> will still work if they don't... And they will probably say: "If it
>>>>>>>>> ain't
>>>>>>>>> broken, I won't fix it." ;-)
>>>>>>>>
>>>>>>>> However, deprecation warnings are a strong hint that failure is
>>>>>>>> imminent, and they may wish to prepare for the change.
>>>>>>>
>>>>>>> Yes. We should advertise the list of exceptions that are going to be
>>>>>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>>>>>> them in 2.2.
>>>>>>> The preparation is to have a perl (or sed or ...) script ready.
>>>>>>>
>>>>>> I think we all agree on the deprecations. I understand your view,
>>>>>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>>>>>> to 3.0; but don't you agree it would be helpful for them to be able to
>>>>>> start - even just with new code they are developing - using the new
>>>>>> user
>>>>>> exception, assuming we can introduce it in 2.2 without breaking
>>>>>> anything?
>>>>>>
>>>>>> Luc / Sebb - can you see any real backward compat issue? Would this
>>>>>> change force a recompile?
>>>>>
>>>>> I don't think a recompile should be needed because the new exceptions
>>>>> going out of the complete integration algorithm are now unchecked, and
>>>>> in fact since the current exception are checked exception, existing
>>>>> user
>>>>> code probably already catches them.
>>>>
>>>> Should be easy enough to check with some actual source.
>>>
>>> I just checked with an old tutorial, compiled with 2.1.
>>> It runs perfectly and throws exceptions correctly with both 2.1 and the
>>> current version in 2.X branch with the proposed change, without
>>> recompiling.
>>
>> What happens when you try to recompile it against a new jar built from
>> the current sources?
>
> The compiler displays a warning, as expected:
> Note: ODEExample.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> Luc
>
Great. Then +1 for the change.
>>
>> Phil
>>>
>>> Luc
>>>
>>>>
>>>>> Luc
>>>>>
>>>>>>
>>>>>> Phil
>>>>>>>
>>>>>>> Best,
>>>>>>> Gilles
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] preparing smooth interface upgrade for users
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 19/11/2010 16:39, Phil Steitz a écrit :
> On 11/19/10 8:52 AM, Luc Maisonobe wrote:
>> Le 17/11/2010 21:08, sebb a écrit :
>>> On 17 November 2010 19:53, Luc Maisonobe<Lu...@free.fr> wrote:
>>>> Le 17/11/2010 13:48, Phil Steitz a écrit :
>>>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>>>>> [...]
>>>>>>>>> I think this transition is the smoother path for our users. Do you
>>>>>>>>> think
>>>>>>>>> this change is the way to go ?
>>>>>>>>
>>>>>>>> -0
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>>
>>>>>>>> My first impression is that it is a lot of changes for 2.2
>>>>>>>> without any
>>>>>>>> benefit when users will switch to 3.0; they will still have to scan
>>>>>>>> their
>>>>>>>> code for all the exceptions that will have disappeared.
>>>>>>>
>>>>>>> Won't the deprecations take care of that?
>>>>>>
>>>>>> I didn't mean that they have to scan "manually", just that they will
>>>>>> have to
>>>>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>>>>> work).
>>>>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>>>>> rule in
>>>>>> 2.2.
>>>>>
>>>>> I think what Luc is suggesting is that by introducing
>>>>> MathUserException
>>>>> in 2.2 without a material compatibility break (i.e. nothing that would
>>>>> actually break any 2.1 code) we could set users to start doing this
>>>>> work
>>>>> incrementally before 3.0 is released. That seems like a good idea
>>>>> to me
>>>>> IIUC what the impacts are.
>>>>
>>>> You are right, this is exactly what I try to do.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2,
>>>>>>>> you would
>>>>>>>> have to explain to users that it's better that they do it but
>>>>>>>> that it
>>>>>>>> will still work if they don't... And they will probably say: "If it
>>>>>>>> ain't
>>>>>>>> broken, I won't fix it." ;-)
>>>>>>>
>>>>>>> However, deprecation warnings are a strong hint that failure is
>>>>>>> imminent, and they may wish to prepare for the change.
>>>>>>
>>>>>> Yes. We should advertise the list of exceptions that are going to be
>>>>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>>>>> them in 2.2.
>>>>>> The preparation is to have a perl (or sed or ...) script ready.
>>>>>>
>>>>> I think we all agree on the deprecations. I understand your view,
>>>>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>>>>> to 3.0; but don't you agree it would be helpful for them to be able to
>>>>> start - even just with new code they are developing - using the new
>>>>> user
>>>>> exception, assuming we can introduce it in 2.2 without breaking
>>>>> anything?
>>>>>
>>>>> Luc / Sebb - can you see any real backward compat issue? Would this
>>>>> change force a recompile?
>>>>
>>>> I don't think a recompile should be needed because the new exceptions
>>>> going out of the complete integration algorithm are now unchecked, and
>>>> in fact since the current exception are checked exception, existing
>>>> user
>>>> code probably already catches them.
>>>
>>> Should be easy enough to check with some actual source.
>>
>> I just checked with an old tutorial, compiled with 2.1.
>> It runs perfectly and throws exceptions correctly with both 2.1 and the
>> current version in 2.X branch with the proposed change, without
>> recompiling.
>
> What happens when you try to recompile it against a new jar built from
> the current sources?
The compiler displays a warning, as expected:
Note: ODEExample.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Luc
>
> Phil
>>
>> Luc
>>
>>>
>>>> Luc
>>>>
>>>>>
>>>>> Phil
>>>>>>
>>>>>> Best,
>>>>>> Gilles
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by Phil Steitz <ph...@gmail.com>.
On 11/19/10 8:52 AM, Luc Maisonobe wrote:
> Le 17/11/2010 21:08, sebb a écrit :
>> On 17 November 2010 19:53, Luc Maisonobe<Lu...@free.fr> wrote:
>>> Le 17/11/2010 13:48, Phil Steitz a écrit :
>>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>>>> [...]
>>>>>>>> I think this transition is the smoother path for our users. Do you
>>>>>>>> think
>>>>>>>> this change is the way to go ?
>>>>>>>
>>>>>>> -0
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>>
>>>>>>> My first impression is that it is a lot of changes for 2.2 without any
>>>>>>> benefit when users will switch to 3.0; they will still have to scan
>>>>>>> their
>>>>>>> code for all the exceptions that will have disappeared.
>>>>>>
>>>>>> Won't the deprecations take care of that?
>>>>>
>>>>> I didn't mean that they have to scan "manually", just that they will
>>>>> have to
>>>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>>>> work).
>>>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>>>> rule in
>>>>> 2.2.
>>>>
>>>> I think what Luc is suggesting is that by introducing MathUserException
>>>> in 2.2 without a material compatibility break (i.e. nothing that would
>>>> actually break any 2.1 code) we could set users to start doing this work
>>>> incrementally before 3.0 is released. That seems like a good idea to me
>>>> IIUC what the impacts are.
>>>
>>> You are right, this is exactly what I try to do.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
>>>>>>> have to explain to users that it's better that they do it but that it
>>>>>>> will still work if they don't... And they will probably say: "If it
>>>>>>> ain't
>>>>>>> broken, I won't fix it." ;-)
>>>>>>
>>>>>> However, deprecation warnings are a strong hint that failure is
>>>>>> imminent, and they may wish to prepare for the change.
>>>>>
>>>>> Yes. We should advertise the list of exceptions that are going to be
>>>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>>>> them in 2.2.
>>>>> The preparation is to have a perl (or sed or ...) script ready.
>>>>>
>>>> I think we all agree on the deprecations. I understand your view,
>>>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>>>> to 3.0; but don't you agree it would be helpful for them to be able to
>>>> start - even just with new code they are developing - using the new user
>>>> exception, assuming we can introduce it in 2.2 without breaking anything?
>>>>
>>>> Luc / Sebb - can you see any real backward compat issue? Would this
>>>> change force a recompile?
>>>
>>> I don't think a recompile should be needed because the new exceptions
>>> going out of the complete integration algorithm are now unchecked, and
>>> in fact since the current exception are checked exception, existing user
>>> code probably already catches them.
>>
>> Should be easy enough to check with some actual source.
>
> I just checked with an old tutorial, compiled with 2.1.
> It runs perfectly and throws exceptions correctly with both 2.1 and the
> current version in 2.X branch with the proposed change, without recompiling.
What happens when you try to recompile it against a new jar built
from the current sources?
Phil
>
> Luc
>
>>
>>> Luc
>>>
>>>>
>>>> Phil
>>>>>
>>>>> Best,
>>>>> Gilles
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] preparing smooth interface upgrade for users
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 17/11/2010 21:08, sebb a écrit :
> On 17 November 2010 19:53, Luc Maisonobe <Lu...@free.fr> wrote:
>> Le 17/11/2010 13:48, Phil Steitz a écrit :
>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>>> [...]
>>>>>>> I think this transition is the smoother path for our users. Do you
>>>>>>> think
>>>>>>> this change is the way to go ?
>>>>>>
>>>>>> -0
>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>> My first impression is that it is a lot of changes for 2.2 without any
>>>>>> benefit when users will switch to 3.0; they will still have to scan
>>>>>> their
>>>>>> code for all the exceptions that will have disappeared.
>>>>>
>>>>> Won't the deprecations take care of that?
>>>>
>>>> I didn't mean that they have to scan "manually", just that they will
>>>> have to
>>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>>> work).
>>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>>> rule in
>>>> 2.2.
>>>
>>> I think what Luc is suggesting is that by introducing MathUserException
>>> in 2.2 without a material compatibility break (i.e. nothing that would
>>> actually break any 2.1 code) we could set users to start doing this work
>>> incrementally before 3.0 is released. That seems like a good idea to me
>>> IIUC what the impacts are.
>>
>> You are right, this is exactly what I try to do.
>>
>>>
>>>>
>>>>>
>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
>>>>>> have to explain to users that it's better that they do it but that it
>>>>>> will still work if they don't... And they will probably say: "If it
>>>>>> ain't
>>>>>> broken, I won't fix it." ;-)
>>>>>
>>>>> However, deprecation warnings are a strong hint that failure is
>>>>> imminent, and they may wish to prepare for the change.
>>>>
>>>> Yes. We should advertise the list of exceptions that are going to be
>>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>>> them in 2.2.
>>>> The preparation is to have a perl (or sed or ...) script ready.
>>>>
>>> I think we all agree on the deprecations. I understand your view,
>>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>>> to 3.0; but don't you agree it would be helpful for them to be able to
>>> start - even just with new code they are developing - using the new user
>>> exception, assuming we can introduce it in 2.2 without breaking anything?
>>>
>>> Luc / Sebb - can you see any real backward compat issue? Would this
>>> change force a recompile?
>>
>> I don't think a recompile should be needed because the new exceptions
>> going out of the complete integration algorithm are now unchecked, and
>> in fact since the current exception are checked exception, existing user
>> code probably already catches them.
>
> Should be easy enough to check with some actual source.
I just checked with an old tutorial, compiled with 2.1.
It runs perfectly and throws exceptions correctly with both 2.1 and the
current version in 2.X branch with the proposed change, without recompiling.
Luc
>
>> Luc
>>
>>>
>>> Phil
>>>>
>>>> Best,
>>>> Gilles
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by sebb <se...@gmail.com>.
On 17 November 2010 19:53, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 17/11/2010 13:48, Phil Steitz a écrit :
>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>> [...]
>>>>>> I think this transition is the smoother path for our users. Do you
>>>>>> think
>>>>>> this change is the way to go ?
>>>>>
>>>>> -0
>>>>
>>>> +1
>>>>
>>>>>
>>>>> My first impression is that it is a lot of changes for 2.2 without any
>>>>> benefit when users will switch to 3.0; they will still have to scan
>>>>> their
>>>>> code for all the exceptions that will have disappeared.
>>>>
>>>> Won't the deprecations take care of that?
>>>
>>> I didn't mean that they have to scan "manually", just that they will
>>> have to
>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>> work).
>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>> rule in
>>> 2.2.
>>
>> I think what Luc is suggesting is that by introducing MathUserException
>> in 2.2 without a material compatibility break (i.e. nothing that would
>> actually break any 2.1 code) we could set users to start doing this work
>> incrementally before 3.0 is released. That seems like a good idea to me
>> IIUC what the impacts are.
>
> You are right, this is exactly what I try to do.
>
>>
>>>
>>>>
>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
>>>>> have to explain to users that it's better that they do it but that it
>>>>> will still work if they don't... And they will probably say: "If it
>>>>> ain't
>>>>> broken, I won't fix it." ;-)
>>>>
>>>> However, deprecation warnings are a strong hint that failure is
>>>> imminent, and they may wish to prepare for the change.
>>>
>>> Yes. We should advertise the list of exceptions that are going to be
>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>> them in 2.2.
>>> The preparation is to have a perl (or sed or ...) script ready.
>>>
>> I think we all agree on the deprecations. I understand your view,
>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>> to 3.0; but don't you agree it would be helpful for them to be able to
>> start - even just with new code they are developing - using the new user
>> exception, assuming we can introduce it in 2.2 without breaking anything?
>>
>> Luc / Sebb - can you see any real backward compat issue? Would this
>> change force a recompile?
>
> I don't think a recompile should be needed because the new exceptions
> going out of the complete integration algorithm are now unchecked, and
> in fact since the current exception are checked exception, existing user
> code probably already catches them.
Should be easy enough to check with some actual source.
> Luc
>
>>
>> Phil
>>>
>>> Best,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] preparing smooth interface upgrade for users
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 17/11/2010 13:48, Phil Steitz a écrit :
> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>> [...]
>>>>> I think this transition is the smoother path for our users. Do you
>>>>> think
>>>>> this change is the way to go ?
>>>>
>>>> -0
>>>
>>> +1
>>>
>>>>
>>>> My first impression is that it is a lot of changes for 2.2 without any
>>>> benefit when users will switch to 3.0; they will still have to scan
>>>> their
>>>> code for all the exceptions that will have disappeared.
>>>
>>> Won't the deprecations take care of that?
>>
>> I didn't mean that they have to scan "manually", just that they will
>> have to
>> make the same change in 3.0 as they would in 2.2 (not more, not less
>> work).
>> Hence, I see no benefit in breaking the "no compatibility breaking"
>> rule in
>> 2.2.
>
> I think what Luc is suggesting is that by introducing MathUserException
> in 2.2 without a material compatibility break (i.e. nothing that would
> actually break any 2.1 code) we could set users to start doing this work
> incrementally before 3.0 is released. That seems like a good idea to me
> IIUC what the impacts are.
You are right, this is exactly what I try to do.
>
>>
>>>
>>>> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
>>>> have to explain to users that it's better that they do it but that it
>>>> will still work if they don't... And they will probably say: "If it
>>>> ain't
>>>> broken, I won't fix it." ;-)
>>>
>>> However, deprecation warnings are a strong hint that failure is
>>> imminent, and they may wish to prepare for the change.
>>
>> Yes. We should advertise the list of exceptions that are going to be
>> replaced by "MathUserException" when users switch 3.0, by deprecating
>> them in 2.2.
>> The preparation is to have a perl (or sed or ...) script ready.
>>
> I think we all agree on the deprecations. I understand your view,
> Gilles, that Luc's suggestion does not reduce work for those upgrading
> to 3.0; but don't you agree it would be helpful for them to be able to
> start - even just with new code they are developing - using the new user
> exception, assuming we can introduce it in 2.2 without breaking anything?
>
> Luc / Sebb - can you see any real backward compat issue? Would this
> change force a recompile?
I don't think a recompile should be needed because the new exceptions
going out of the complete integration algorithm are now unchecked, and
in fact since the current exception are checked exception, existing user
code probably already catches them.
Luc
>
> Phil
>>
>> Best,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by Phil Steitz <ph...@gmail.com>.
On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>> [...]
>>>> I think this transition is the smoother path for our users. Do you think
>>>> this change is the way to go ?
>>>
>>> -0
>>
>> +1
>>
>>>
>>> My first impression is that it is a lot of changes for 2.2 without any
>>> benefit when users will switch to 3.0; they will still have to scan their
>>> code for all the exceptions that will have disappeared.
>>
>> Won't the deprecations take care of that?
>
> I didn't mean that they have to scan "manually", just that they will have to
> make the same change in 3.0 as they would in 2.2 (not more, not less work).
> Hence, I see no benefit in breaking the "no compatibility breaking" rule in
> 2.2.
I think what Luc is suggesting is that by introducing
MathUserException in 2.2 without a material compatibility break
(i.e. nothing that would actually break any 2.1 code) we could set
users to start doing this work incrementally before 3.0 is released.
That seems like a good idea to me IIUC what the impacts are.
>
>>
>>> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
>>> have to explain to users that it's better that they do it but that it
>>> will still work if they don't... And they will probably say: "If it ain't
>>> broken, I won't fix it." ;-)
>>
>> However, deprecation warnings are a strong hint that failure is
>> imminent, and they may wish to prepare for the change.
>
> Yes. We should advertise the list of exceptions that are going to be
> replaced by "MathUserException" when users switch 3.0, by deprecating
> them in 2.2.
> The preparation is to have a perl (or sed or ...) script ready.
>
I think we all agree on the deprecations. I understand your view,
Gilles, that Luc's suggestion does not reduce work for those
upgrading to 3.0; but don't you agree it would be helpful for them
to be able to start - even just with new code they are developing -
using the new user exception, assuming we can introduce it in 2.2
without breaking anything?
Luc / Sebb - can you see any real backward compat issue? Would this
change force a recompile?
Phil
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [math] preparing smooth interface upgrade for users
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >> [...]
> >> I think this transition is the smoother path for our users. Do you think
> >> this change is the way to go ?
> >
> > -0
>
> +1
>
> >
> > My first impression is that it is a lot of changes for 2.2 without any
> > benefit when users will switch to 3.0; they will still have to scan their
> > code for all the exceptions that will have disappeared.
>
> Won't the deprecations take care of that?
I didn't mean that they have to scan "manually", just that they will have to
make the same change in 3.0 as they would in 2.2 (not more, not less work).
Hence, I see no benefit in breaking the "no compatibility breaking" rule in
2.2.
>
> > In 3.0 it will clear that they *have* to do it while, in 2.2, you would
> > have to explain to users that it's better that they do it but that it
> > will still work if they don't... And they will probably say: "If it ain't
> > broken, I won't fix it." ;-)
>
> However, deprecation warnings are a strong hint that failure is
> imminent, and they may wish to prepare for the change.
Yes. We should advertise the list of exceptions that are going to be
replaced by "MathUserException" when users switch 3.0, by deprecating
them in 2.2.
The preparation is to have a perl (or sed or ...) script ready.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] preparing smooth interface upgrade for users
Posted by sebb <se...@gmail.com>.
On 16 November 2010 23:19, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> As we are changing a lot of things in 3.0, it would be interesting to
>> have 2.2 help users smoothly adapt their code. Many exceptions have/will
>> be changed and some of them are used in public interfaces users have to
>> implement. Typical examples are FirstOrderDifferentialEquations and the
>> associated DerivativeException, or UnivariateRealFunction and
>> FunctionEvaluationException.
>>
>> Discussion on MATH-425 lead to group these user-specific exception as
>> one single unchecked exception: MathUserException. This choice has the
>> additional advantage that when a user uses an ode solver inside an
>> optimizer for example, the same exception can be used at both levels and
>> an error condition occurring at very low level can be handled at top
>> level without problem.
>>
>> In order to help users, I am going to use for 2.2 a transition scheme
>> where the exceptions DerivativeException, FunctionEvaluationException
>> and similar ones would all be deprecated and at the same time their base
>> class would be changed to the new MathUserException. Then the user
>> methods in the public interfaces would be declared to throw
>> MathUserException. So we would change from the current design which is:
>>
>> public class DerivativeException extends MathException {...}
>>
>> public interface FirstOrderDifferentialEquations {
>> public void computeDerivatives(...) throws DerivativeException;
>> }
>>
>> to a new design which would be:
>>
>> public class MathUserException extends RuntimeException {...}
>>
>> @Deprecated
>> public class DerivativeException extends MathUserException {...}
>>
>> public interface FirstOrderDifferentialEquations {
>> public void computeDerivatives(...) throws MathUserException;
>> }
>>
>> Then in 3.0 the deprecated exceptions would be removed (I think Gilles
>> already did it).
>>
>> This is an interface change, but I think it is worth doing it and it
>> does provide a sufficient level of compatibility. These interfaces are
>> intended to be implemented by user, to implement their own business
>> problems. Many already have implemented the interface in its 2.1
>> version, probably using a DerivativeException for their error handling.
>> Since DerivativeException would still be there in 2.2 and it would
>> extend MathUserException, these implementations would both continue to
>> work in 2.2 and new users and new implementations could already use the
>> new MathUSerExceptions. The only pain for existing implementations would
>> be to see warnings about the deprecated exceptions. Users would have
>> some time to adapt their code and use directly MathUserException, which
>> provide at least everything DerivativeException did provide up to now.
>>
>> I guess CLIRR will complain and consider this an incompatible change. It
>> is true from a caller perspective since now we should expect
>> MathUserExceptions rather than only DerivativeExceptions. However,
>> MathUSerException is unchecked and the callers for these interfaces are
>> the commons-math methods, which we will adapt. These interfaces are not
>> intened to be called by user code, they are intended so that user code
>> can be called by our library.
>>
>> I think this transition is the smoother path for our users. Do you think
>> this change is the way to go ?
>
> -0
+1
>
> My first impression is that it is a lot of changes for 2.2 without any
> benefit when users will switch to 3.0; they will still have to scan their
> code for all the exceptions that will have disappeared.
Won't the deprecations take care of that?
> In 3.0 it will clear that they *have* to do it while, in 2.2, you would
> have to explain to users that it's better that they do it but that it
> will still work if they don't... And they will probably say: "If it ain't
> broken, I won't fix it." ;-)
However, deprecation warnings are a strong hint that failure is
imminent, and they may wish to prepare for the change.
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [math] preparing smooth interface upgrade for users
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> As we are changing a lot of things in 3.0, it would be interesting to
> have 2.2 help users smoothly adapt their code. Many exceptions have/will
> be changed and some of them are used in public interfaces users have to
> implement. Typical examples are FirstOrderDifferentialEquations and the
> associated DerivativeException, or UnivariateRealFunction and
> FunctionEvaluationException.
>
> Discussion on MATH-425 lead to group these user-specific exception as
> one single unchecked exception: MathUserException. This choice has the
> additional advantage that when a user uses an ode solver inside an
> optimizer for example, the same exception can be used at both levels and
> an error condition occurring at very low level can be handled at top
> level without problem.
>
> In order to help users, I am going to use for 2.2 a transition scheme
> where the exceptions DerivativeException, FunctionEvaluationException
> and similar ones would all be deprecated and at the same time their base
> class would be changed to the new MathUserException. Then the user
> methods in the public interfaces would be declared to throw
> MathUserException. So we would change from the current design which is:
>
> public class DerivativeException extends MathException {...}
>
> public interface FirstOrderDifferentialEquations {
> public void computeDerivatives(...) throws DerivativeException;
> }
>
> to a new design which would be:
>
> public class MathUserException extends RuntimeException {...}
>
> @Deprecated
> public class DerivativeException extends MathUserException {...}
>
> public interface FirstOrderDifferentialEquations {
> public void computeDerivatives(...) throws MathUserException;
> }
>
> Then in 3.0 the deprecated exceptions would be removed (I think Gilles
> already did it).
>
> This is an interface change, but I think it is worth doing it and it
> does provide a sufficient level of compatibility. These interfaces are
> intended to be implemented by user, to implement their own business
> problems. Many already have implemented the interface in its 2.1
> version, probably using a DerivativeException for their error handling.
> Since DerivativeException would still be there in 2.2 and it would
> extend MathUserException, these implementations would both continue to
> work in 2.2 and new users and new implementations could already use the
> new MathUSerExceptions. The only pain for existing implementations would
> be to see warnings about the deprecated exceptions. Users would have
> some time to adapt their code and use directly MathUserException, which
> provide at least everything DerivativeException did provide up to now.
>
> I guess CLIRR will complain and consider this an incompatible change. It
> is true from a caller perspective since now we should expect
> MathUserExceptions rather than only DerivativeExceptions. However,
> MathUSerException is unchecked and the callers for these interfaces are
> the commons-math methods, which we will adapt. These interfaces are not
> intened to be called by user code, they are intended so that user code
> can be called by our library.
>
> I think this transition is the smoother path for our users. Do you think
> this change is the way to go ?
-0
My first impression is that it is a lot of changes for 2.2 without any
benefit when users will switch to 3.0; they will still have to scan their
code for all the exceptions that will have disappeared.
In 3.0 it will clear that they *have* to do it while, in 2.2, you would
have to explain to users that it's better that they do it but that it
will still work if they don't... And they will probably say: "If it ain't
broken, I won't fix it." ;-)
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org