On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote:
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.
I did consider this possibility, but it is not backwards compatible.
Many browsers, including WebKit and Gecko based ones, pass any
arguments to setTimeout past delay to the timeout function. So
setTimeout(foo, 0.001, false) would call foo with a first parameter of
false. Since this construct already has a meaning, I don't think we
can change it for only the boolean case.
I agree with you that excess of APIs can confuse Web developers.
Normally our preference is to extend existing facilities. Thus the
WebKit project's focus on extending existing technologies like HTML
and CSS, as opposed to investing heavily in total reinventions like
XForms. Not only are ocean-boiling excercises a waste of time for
authors, but we as browser engine developers will have to continue to
support the older technologies forever anyway.
In this case, I think the preponderance of the evidence weighs in
favor of new API, in part because the existing calls are impossible to
extend compatibly with extra arguments, and because it is likely
desirable to feature-test for highres timers, and the extra argument
approach does not allow for that.
Regards,
Maciej
P.S. I encourage further feedback to be sent to public-webapps for
those who are willing.
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
