I'm not opposed to any of this; and the new API is definitely nicer. I'll bring up a devil's advocate point. One thing I hate is the Microsoft-style smorgasboard of APIs. When you want to start a timer, you have 6 to choose from, and I hope we can avoid similar problems in the DOM. If keeping the number of APIs is a worthy goal, we could just augment the existing API in a backward comaptible way:
setTimeout(callback, milliseconds, protect_against_cpu_looping = true) Example to set a 1us timer: setTimeout("foo()", 0.001, false) setInterval could be modified similarly. There are some downsides; such as difficulty of knowing what resolution your browser supports; but maybe that is an advantage as well. You also lose the new features, and OO style. But, it does avoid API-soup. Mike On Thu, Oct 2, 2008 at 6:07 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote: > > On a separate thread, it was discussed that it is useful to support > microsecond resolution for future proofness. > > > I proposed seconds so that it was more clear that fractional versions could > be used, and because specifying microseconds as fractional milliseconds > seems awkward to me. But whatever the baseline resolution, I think > fractional values should be supported so there isn't an artificial floor to > the resolution on future hardware. > > - Maciej > > > -Darin > > > On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher <[EMAIL PROTECTED]>wrote: > >> Why double delayInSeconds and not milliseconds to stay consistent? >> >> On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote: >> >> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote: >> >>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >>> > I don't really like the overengineered version. I like the "fairly >>> > minimalist" version best, but is there anything from the >>> > overengineered version that should be added to it? >>> >>> I like the "fairly minimalist" version best as well. >>> >>> The stop() method does seem a little lonely on the Timer interface all >>> by itself. >>> >>> If others think any other members from the "overengineered" version >>> are important I would welcome them to keep stop() company. >>> >> >> +1. My ideal would be the following: >> >> Timer startTimer(double delayInSeconds, bool repeating, >> Function callback); >> >> interface Timer { >> void stop(); >> void resume(); >> void setDelay(double delayInSeconds); >> } >> >> That would cover the majority of cases I've seen in real-world javascript >> code. The argument for setDelay is wanting to be able to tweak the delay on >> the fly (e.g. Google Page Creator has autosave code that gets a response >> from the server with a longer delay time when the server is overloaded). >> >> Ojan >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev