Bringing setTimeout to ECMAScript

Peter van der Zee ecma at qfox.nl
Fri Mar 18 05:54:53 PDT 2011


+1 to standardizing the timer family.

I always thought this wasn't in because the specification didn't have
any asynchronism and specifying timers would open Pandora's box.

- peter

On Fri, Mar 18, 2011 at 1:51 PM, David Bruant <bruant at enseirb-matmeca.fr>wrote:

>  Hi,
>
> _Foreword_
> Each time I write "setTimeout", I mean "setTimeout and setInterval (and
> there clear functions)" (please forgive the recursive flaw)
>
> _Introduction_
> Before the concurrency proposal (
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency), a pure
> ECMAScript program had a start and an end, that was it. No event loop, no
> asynchronous callback, etc.
> If ECMAScript standardizes this proposal or another, there will be a need
> to standardize an event loop in a way or another. Adding a timing aspect to
> this event loop and setTimeout can be standardized in ECMAScript.
>
> _Current_standardization_state_
> setTimeout isn't part of ECMAScript. setTimeout is nonetheless standardized
> as part of "HTML Standard" (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers).
> Besides the "task" dependency (which is part of the standardized event-loop
> in the same document:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task),
> this is more or less ECMAScript.
>
> _Current_use_
> As anyone will have certainly noticed, setTimeout has no reason to be
> considered as client-side web specific. And, as a matter of fact, there is a
> setTimeout in node.js and in ActionScript apparently. I wouldn't be
> surprised if most (if not all) ECMAScript-based languages had a setTimeout
> function consistently.
>
> For all these reasons, I am wondering if setTimeout wouldn't be had being
> standardized in ECMAScript itself.
>
> _How?_
> I currently see two main tracks:
> * Standardize it as it is.
> * Standardize a more powerful mecanism and standardize setTimeout as an
> implementation based on this mecanism. If setTimeout had been considered as
> not flexible enough by some people, this could be an occasion to fit their
> use case (I personnally have no suggestion on the matter)
> I am not familiar with promises, but after reading a bit about it and
> seeing a presentation on the topic, I intuit that it may not be very
> difficult to add a timing aspect to it based on which setTimeout could be
> implemented.
>
> _Advantages_
> * As said, it could be an occasion to fix flexibility issues that people
> would find to setTimeout
> * Define a strict mode behavior to it. Currently, people can pass strings
> as first argument to setTimeout. There is currently a spec hole in what
> happens in strict mode for setTimeout.
> I would be in favor to throw an exception if people use strings in
> setTimeout in strict mode (maybe it's too late to suggest that since FF4
> ships in less than a week?). Anyway, there is room for other ideas like
> standardizing strict eval for strings as first argument in strict mode. My
> main goal is to discuss the issue.
>
>
> I haven't found any trace of previous discussion of this topic. Has there
> been any?
>
> David
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110318/73c4ca2f/attachment.html>


More information about the es-discuss mailing list