[interfacekit] Re: BMessageRunner: negative interval

> > a question about behavioral compatibility. BMessageRunner can be
> > initialized with a negative time interval. This is semantical
> > nonsense,
> > but it seems to cause the messages to be sent as fast as possible. I
> > suspect that this is a bug caused by sloppy parameter checking, 
> > since
> > supplying 0 for the interval is not allowed -- InitCheck() returns
> > B_ERROR in that case.
> > 
> > I tend to forbid all values <= 0. Are there objections?
> > 
> > Oh I forgot to mention, that those negative numbers work well with
> > small positive count parameters (the number specifying how many 
> > times
> > the message shall be sent), but obviously the target's message port
> > is
> > flooded when count is -1 (unlimited number of repetitions).
> 
> Err, I guess, I sent my mail a bit early. I was wrong with my
> suspicion, that the messages are sent with maximal speed. If the
> supplied time interval is smaller than a minimal value (50000 if it
> isn't machine dependent), then this minimal interval is used instead.
> This is also the case for negative values. So if I copy this behavior,
> I think, for consistency the handling should be the same for 0,
> shouldn't it?

That seems okay to me. 

And now that you mention it, I have similar question wrt 
BRoster::GetRecentDocuments and friends. Anytime there is at least one 
recent item to return (i.e. any supplied filtering mime type or app sig 
didn't rule out every possible item in the list) and the given number 
of "maximum items to return" is <= 0, the function returns one item. 
The idea of returning zero items is not undefined, however, as that is 
what the function does when the supplied mime type filter doesn't match 
any of the items in the list. Thus, it makes more sense to me to return 
zero items if the maxCount parameter is <= 0 (the functions themselves 
return void, so there's no error code to return). Any objections?

-Tyler

Other related posts: