On Oct 3, 2008, at 10:43 AM, Aaron Boodman wrote:
Hi Maciej,
Thanks for raising this. It's a good addition to the web platform. I'm
definitely +1 to the idea.
2008/10/2 Maciej Stachowiak <[EMAIL PROTECTED]>:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing
microseconds as fractional milliseconds seems quite weird.
To me, fractional milliseconds does not seem weird. On the webkit-dev
thread, Peter Speck pointed out [1] that the unit of time in web
development is milliseconds. Dates are in milliseconds, setTimeout
takes millisecond arguments, etc. So to me, it would be weird to have
a new timer API that suddenly uses seconds. And I tend to agree with
Peter that doing so would be a common source of bugs for web
developers.
I find the fact that Dates are in milliseconds convincing. It should
be in milliseconds so people can reasonably do math with Dates and
elapsedTime.
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the "repeating" or even the "delayInSeconds" arguments
should be optional, defaulting to false and 0 respectively, and
possibly in combination with the above suggestion.
You mentioned [2] that this is a bit weird because the function can be
quite long and then it reads poorly for anonymous functions.
I see your point, but we already have that problem with setTimeout and
setInterval. And I feel like it's more important to have consistency
where possible with these well-established APIs than fix this issue.
I don't think consistency on argument order is critical, but I see
your point. We won't be 100% copying the argument order anyway since I
don't think it is worth carrying over the quirky extra argument
behavior of setTimeout and setInterval.
Regards,
Maciej
