On 11/02/2010 10:07 AM, Heiko W.Rupp wrote:
Hey,
Am 02.11.2010 um 14:59 schrieb Ian Springer:
>> - boolean enableDisable = (collectionInterval> 0);
>> + boolean enable = (collectionInterval>= 0);
I am not sure I like this overloading too much, even if it makes sense.
A more explicit (= additional parameter) could be better.
Heiko
This is mostly a stylist debate over API. It can be done either way,
and I don't think one is intrinsically more correct than another.
A similar stylistic debate rages over whether, when you know an API will
change in the future, you create an aggregate object to contain that
likely delta or keep the argument list flat. It's the difference between:
"flat" style
v1 - method(staticArg1, staticArg2, configurableArg1)
v2 - method(staticArg1, staticArg2, configurableArg1, configurableArg2)
"aggregate" style
method(staticArg1, staticArg2, configurableArg)
v1 - struct Configurable {
arg1;
}
v2 - struct Configurable {
arg1;
arg2;
}
In both cases, the API is still changing, and there are various pros and
cons that can be argued for either style. In the end, it's a
distinction that requires no less validation on the arguments, and no
less documentation for pre- and post-conditions.
One instance, off the top of my head, that overloads the meaning of a
parameter concerning an interval is in job and/or request scheduling.
In GWT you have RequestBuilder.setTimeoutMillis(int timeoutMillis),
where the value of 0 is processed in a special way that disables the
request timeout (effectively an infinite timeout). The method still has
validation for the range of values that are invalid timeouts (in this
case, negative numbers), but the JDoc had to specifically call out what
post-condition for all valid values (zero disables the timeout, and
greater-than-zero enables/sets the timeout).
In the end, I'm not really partial to one style over the other...just
wanted to point out this is one of those slippery slopes.