Hi David, I think this is an excellent idea. I will add it to the concurrency strawman.
However, since the concurrency strawman is on he agenda for May and I'm currently overloaded preparing for next week's March meeting, I won't get to this till April. Once I have a draft, further feedback would be great. Thanks! On Fri, Mar 18, 2011 at 5:51 AM, David Bruant <bru...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
