fix for MeasurementScheduleManagerBean.update

Joseph Marques jmarques at redhat.com
Tue Nov 2 15:41:29 UTC 2010


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.


More information about the rhq-devel mailing list