commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [2/2] [math] Add getXmax, getXmin, getYmax, getYmin to BicubicInterpolatingFunction.
Date Mon, 06 Jul 2015 10:25:17 GMT
On Sun, 05 Jul 2015 22:31:27 +0200, Luc Maisonobe wrote:
> Le 05/07/2015 21:39, Gilles a écrit :
>> On Sun, 05 Jul 2015 18:32:16 -0000, luc@apache.org wrote:
>>> Add getXmax, getXmin, getYmax, getYmin to 
>>> BicubicInterpolatingFunction.
>>>
>>> These can be useful to manage an OutOfRangeException without the 
>>> need to
>>> access the original x and y arrays.
>>
>> IIRC, this "feature" has been requested before but eventually 
>> without a
>> convincing use-case. [In general, the user knows the valid range 
>> since
>> he called "interpolate".]
>
> User do not always keep the arrays. As the interpolator does jeep 
> them,
> we just have to ask it.

That might be the case but I'm talking of agreeing on the API!

Personally, and only if the feature is useful, I'd have considered
methods like:

public double[] getInterpolationRangeX() {
   return new double[] { xval[0], xval[xval.length - 1] };
}

>>
>>> Closes #9.
>>
>> Shouldn't we discuss API change on the ML?
>
> If we start discussing every single getter, we will grind to halt. We
> are already not responsive enough (and I put most of the blame on 
> myself).
>

Isn't that the one rule to abide by?

Git pull requests are not forwarded here anymore. And I find it 
respectful
towards the project's committers, who (try to) comply with the rules, 
that
they are not bypassed.

Please don't take me wrong; I do not mean that everyone should have 
voted
on every topic before a commit is performed; many (most) recent changes 
and
improvements have come about without any such discussions.
However, in this case, I feel that we start again to add "features" 
that
might just be bloat ("because we can").  To please an "anonymous" 
one-time
contributor?  I find it more productive to incite him/her to comply 
with
what we want the library to be (e.g. the method naming scheme) and 
possibly
change the pull request accordingly...

Or please let people say clearly here, that it is fine to commit 
anything
and let the burden of further modification to those who want to 
challenge
it after the fact; possibly leading to further overwrites but the 
proponents
of the preceding version, etc.
IIUC this would be a change of policy.  Please correct if I'm wrong 
(i.e.
the above has always been fine).


Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message