On Mar 19, 2011, at 3:16 AM, Peter van der Zee wrote: > On Sat, Mar 19, 2011 at 1:13 AM, Brendan Eich <[email protected]> wrote: > On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote: > >> +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. > > How so? I created JS and its run-to-completion execution model and setTimeout > all at once in 1995. It has not changed in execution-model semantics since. > > I can't think of a single way to simulate setTimeout in ES5. Correct me if > I'm wrong, but I don't think ES5 exposes a single way of defining a mechanism > like: > > -- > var x = 4; > function f(){ x = 5; print(x); } > timer(f, 1); > print(f); > -- > > Such that it would output 4 before 5. That's what I meant with "didn't have > any asynchronism", fwiw.
That's not the same as "open[ing] Pandora's box". Let's not use asynchronism loosely. "Asynchronous I/O" can mean threads and completion ports. It means shared-memory threads and non-determinism in general. setTimeout does not introduce threads, shared memory among them, or even non-determinism if we spec carefully (browsers have to implement carefully already). > The issues with setTimeout have more been about "core langage" vs. "DOM level > 0", and the lack of a "DOM level 0" standard prior to HTML5. > > What do you mean by that? Why should that influence the choice of including > it in the ECMA spec? What about embedded environments or ssjs? Exactly my point: the historical accidents of what got spec'ed in which standards body, or not spec'ed at all for years, should not overrule other criteria now. If we want to spec setTimeout and event loopage in Ecma TC39, we can consider it on its merits. /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
