Re: ELL API changes before stabilizing

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Hi Mat,

 >
> My whole point here is that I see it as a favorable tradeoff to pass an
> extra '0' to the timeout APIs when subsecond resolution is not required
> rather than have superfluous API calls. It's only a matter of what ELL
> users see in their code, not code efficiency: the current whole-second
> APIs are just wrappers around full-resolution common code anyway. If the
> whole-seconds use case is overly impacted by the extra parameter, then
> the tradeoff may not be favorable.

That is really what I meant.  I want to save the users from typing the 
extra 0 parameter unnecessarily.  We already have 4 arguments to 
l_timeout_create, with lots of potential zeros.

> I agree that nanoseconds are overkill, but I don't mind seeing the
> platform detail filter up to the ELL API level. In practice,
> milliseconds are likely sufficient and would save a lot of '0' keypresses.
>

Hence my question.  Do we actually need to expose nanoseconds?  I can't 
believe someone needs that level of precision.  MS is fine.

If we add the range stuff in, then that's another argument or two, 
depending on representation.

I actually don't mind multiple constructors. They're just shorthands and 
are easier to read than trying to parse the arguments.  We can include a 
range fudge factor as part of the API.  e.g. second version of 
timeout_create fudges by +/- 500ms.  MS versions can fudge by +/- 500 
nanoseconds, etc.

And if someone wants full control, then a full-blown provide-everything 
constructor can be added.

Regards,
-Denis