You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2013/11/12 18:44:13 UTC
[math] undeprecate test(...) in AbstractUnivariateStatistic?
The implementation of this method has been replaced by the
MathArrays extracted version, but deprecating and subsequently
removing it from AbstractUnivariateStatistic eliminates the ability
of subclasses to override and implement their own input array
validation methods. I am -0 on removing that flexibility. Anyone
mind if I remove the deprecation on this method?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 14 Nov 2013 16:09:07 -0800, Phil Steitz wrote:
> On 11/13/13 8:04 AM, Phil Steitz wrote:
>> On 11/13/13 7:52 AM, Gilles wrote:
>>> On Wed, 13 Nov 2013 07:25:22 -0800, Phil Steitz wrote:
>>>> On 11/13/13 2:31 AM, Gilles wrote:
>>>>> On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
>>>>>> The implementation of this method has been replaced by the
>>>>>> MathArrays extracted version, but deprecating and subsequently
>>>>>> removing it from AbstractUnivariateStatistic eliminates the
>>>>>> ability
>>>>>> of subclasses to override and implement their own input array
>>>>>> validation methods. I am -0 on removing that flexibility.
>>>>>> Anyone
>>>>>> mind if I remove the deprecation on this method?
>>>>> What is a use-case for implementing the contract of those
>>>>> methods in
>>>>> more than one way?
>>>> The use case is not a different implementation of the default
>>>> array
>>>> validation provided by the MathArrays version in
>>>> AbstractUnivariateStatistic, but to allow different contracts.
>>>> For
>>>> example, some implementations may be able to handle NaN weights or
>>>> to allow the length parameter to extend beyond the end of the
>>>> array
>>>> (interpreting that to mean just all elements beyond the start
>>>> point). Also, the fact that the test method is *always* called
>>>> before evaluation makes it a convenient extension point for other
>>>> kinds of parameter validation. In any of these cases, the
>>>> contract
>>>> itself would be changed in the override. The point of leaving it
>>>> in
>>>> is to allow the flexibility to change the contract / behavior of
>>>> the
>>>> method that checks the input array for validity.
>>> I fear that it would be fairly confusing to change the contract:
>>> suppose
>>>
>>> public AbstractUnivariateStatistic getStat() {
>>> return new StatWithAnotherContract();
>>> }
>>>
>>> -> the caller who reads the Javadoc of
>>> "AbstractUnivariateStatistic" will
>>> get wrong informations about the behaviour of the returned
>>> instance.
>> But if the subclass *overrides* the method and *replaces* the
>> javadoc the user will see the description of the overridden method.
>> This is pretty standard.
>>
>>> I wonder whether a "validator" class should not be passed as an
>>> argument
>>> to the AbstractUnivariateStatistic constructor...
>> That is over-engineering, IMO and a needless change in the
>> interface. The test(...) methods have been there forever and they
>> provide good default functionality as well as an extension point, as
>> I have tried to describe above.
>>
>> Phil
>
> Are you OK with removing the deprecation, then, Gilles?
I guess so. [One could say that the burden is only on the developer of
a subclass since the methods are protected. Still it would have been
nice to have an example of non-default behaviour (in the userguide?).]
If and when possible, I'd favour changing "test" into something clearer
like "validate".
One nice flexiblity with the possibility to override those methods is
to allow subclasses to deactivate validation! This could possibly
enhance
performance on very large arrays.
Gilles
> I think it
> is best not to make this needless compatibility break and remove the
> flexibility to override.
>
> Any other opinions on this?
>
> Phil
>>>
>>> Gilles
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/13/13 8:04 AM, Phil Steitz wrote:
> On 11/13/13 7:52 AM, Gilles wrote:
>> On Wed, 13 Nov 2013 07:25:22 -0800, Phil Steitz wrote:
>>> On 11/13/13 2:31 AM, Gilles wrote:
>>>> On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
>>>>> The implementation of this method has been replaced by the
>>>>> MathArrays extracted version, but deprecating and subsequently
>>>>> removing it from AbstractUnivariateStatistic eliminates the
>>>>> ability
>>>>> of subclasses to override and implement their own input array
>>>>> validation methods. I am -0 on removing that flexibility. Anyone
>>>>> mind if I remove the deprecation on this method?
>>>> What is a use-case for implementing the contract of those
>>>> methods in
>>>> more than one way?
>>> The use case is not a different implementation of the default array
>>> validation provided by the MathArrays version in
>>> AbstractUnivariateStatistic, but to allow different contracts. For
>>> example, some implementations may be able to handle NaN weights or
>>> to allow the length parameter to extend beyond the end of the array
>>> (interpreting that to mean just all elements beyond the start
>>> point). Also, the fact that the test method is *always* called
>>> before evaluation makes it a convenient extension point for other
>>> kinds of parameter validation. In any of these cases, the contract
>>> itself would be changed in the override. The point of leaving it in
>>> is to allow the flexibility to change the contract / behavior of the
>>> method that checks the input array for validity.
>> I fear that it would be fairly confusing to change the contract:
>> suppose
>>
>> public AbstractUnivariateStatistic getStat() {
>> return new StatWithAnotherContract();
>> }
>>
>> -> the caller who reads the Javadoc of
>> "AbstractUnivariateStatistic" will
>> get wrong informations about the behaviour of the returned instance.
> But if the subclass *overrides* the method and *replaces* the
> javadoc the user will see the description of the overridden method.
> This is pretty standard.
>
>> I wonder whether a "validator" class should not be passed as an
>> argument
>> to the AbstractUnivariateStatistic constructor...
> That is over-engineering, IMO and a needless change in the
> interface. The test(...) methods have been there forever and they
> provide good default functionality as well as an extension point, as
> I have tried to describe above.
>
> Phil
Are you OK with removing the deprecation, then, Gilles? I think it
is best not to make this needless compatibility break and remove the
flexibility to override.
Any other opinions on this?
Phil
>>
>> 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] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/13/13 7:52 AM, Gilles wrote:
> On Wed, 13 Nov 2013 07:25:22 -0800, Phil Steitz wrote:
>> On 11/13/13 2:31 AM, Gilles wrote:
>>> On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
>>>> The implementation of this method has been replaced by the
>>>> MathArrays extracted version, but deprecating and subsequently
>>>> removing it from AbstractUnivariateStatistic eliminates the
>>>> ability
>>>> of subclasses to override and implement their own input array
>>>> validation methods. I am -0 on removing that flexibility. Anyone
>>>> mind if I remove the deprecation on this method?
>>>
>>> What is a use-case for implementing the contract of those
>>> methods in
>>> more than one way?
>>
>> The use case is not a different implementation of the default array
>> validation provided by the MathArrays version in
>> AbstractUnivariateStatistic, but to allow different contracts. For
>> example, some implementations may be able to handle NaN weights or
>> to allow the length parameter to extend beyond the end of the array
>> (interpreting that to mean just all elements beyond the start
>> point). Also, the fact that the test method is *always* called
>> before evaluation makes it a convenient extension point for other
>> kinds of parameter validation. In any of these cases, the contract
>> itself would be changed in the override. The point of leaving it in
>> is to allow the flexibility to change the contract / behavior of the
>> method that checks the input array for validity.
>
> I fear that it would be fairly confusing to change the contract:
> suppose
>
> public AbstractUnivariateStatistic getStat() {
> return new StatWithAnotherContract();
> }
>
> -> the caller who reads the Javadoc of
> "AbstractUnivariateStatistic" will
> get wrong informations about the behaviour of the returned instance.
But if the subclass *overrides* the method and *replaces* the
javadoc the user will see the description of the overridden method.
This is pretty standard.
>
> I wonder whether a "validator" class should not be passed as an
> argument
> to the AbstractUnivariateStatistic constructor...
That is over-engineering, IMO and a needless change in the
interface. The test(...) methods have been there forever and they
provide good default functionality as well as an extension point, as
I have tried to describe above.
Phil
>
>
> 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] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 13 Nov 2013 07:25:22 -0800, Phil Steitz wrote:
> On 11/13/13 2:31 AM, Gilles wrote:
>> On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
>>> The implementation of this method has been replaced by the
>>> MathArrays extracted version, but deprecating and subsequently
>>> removing it from AbstractUnivariateStatistic eliminates the ability
>>> of subclasses to override and implement their own input array
>>> validation methods. I am -0 on removing that flexibility. Anyone
>>> mind if I remove the deprecation on this method?
>>
>> What is a use-case for implementing the contract of those methods in
>> more than one way?
>
> The use case is not a different implementation of the default array
> validation provided by the MathArrays version in
> AbstractUnivariateStatistic, but to allow different contracts. For
> example, some implementations may be able to handle NaN weights or
> to allow the length parameter to extend beyond the end of the array
> (interpreting that to mean just all elements beyond the start
> point). Also, the fact that the test method is *always* called
> before evaluation makes it a convenient extension point for other
> kinds of parameter validation. In any of these cases, the contract
> itself would be changed in the override. The point of leaving it in
> is to allow the flexibility to change the contract / behavior of the
> method that checks the input array for validity.
I fear that it would be fairly confusing to change the contract:
suppose
public AbstractUnivariateStatistic getStat() {
return new StatWithAnotherContract();
}
-> the caller who reads the Javadoc of "AbstractUnivariateStatistic"
will
get wrong informations about the behaviour of the returned instance.
I wonder whether a "validator" class should not be passed as an
argument
to the AbstractUnivariateStatistic constructor...
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/13/13 2:31 AM, Gilles wrote:
> On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
>> The implementation of this method has been replaced by the
>> MathArrays extracted version, but deprecating and subsequently
>> removing it from AbstractUnivariateStatistic eliminates the ability
>> of subclasses to override and implement their own input array
>> validation methods. I am -0 on removing that flexibility. Anyone
>> mind if I remove the deprecation on this method?
>
> What is a use-case for implementing the contract of those methods in
> more than one way?
The use case is not a different implementation of the default array
validation provided by the MathArrays version in
AbstractUnivariateStatistic, but to allow different contracts. For
example, some implementations may be able to handle NaN weights or
to allow the length parameter to extend beyond the end of the array
(interpreting that to mean just all elements beyond the start
point). Also, the fact that the test method is *always* called
before evaluation makes it a convenient extension point for other
kinds of parameter validation. In any of these cases, the contract
itself would be changed in the override. The point of leaving it in
is to allow the flexibility to change the contract / behavior of the
method that checks the input array for validity.
Phil
>
> 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] undeprecate test(...) in AbstractUnivariateStatistic?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 12 Nov 2013 09:44:13 -0800, Phil Steitz wrote:
> The implementation of this method has been replaced by the
> MathArrays extracted version, but deprecating and subsequently
> removing it from AbstractUnivariateStatistic eliminates the ability
> of subclasses to override and implement their own input array
> validation methods. I am -0 on removing that flexibility. Anyone
> mind if I remove the deprecation on this method?
What is a use-case for implementing the contract of those methods in
more than one way?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org