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] undeprecate test(...) in AbstractUnivariateStatistic?
Date Wed, 13 Nov 2013 16:04:03 GMT
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


Mime
View raw message