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-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
