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