On Sat, Mar 19, 2011 at 1:13 AM, Brendan Eich <bren...@mozilla.com> 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.
There's no contradiction: programs including those eval'ed by setTimeout (or
> functions passed instead of a string to eval and called later) must and in
> fact *do not* nest or preempt any other executing JS in correct (to this
> approximation) implementations.
>
Ok, I never meant contradiction. Maybe "Pandora's box" should have been "Let
the cat out of the bag" ;) I just never bothered to mention it (introducing
timers) on esdiscuss. Seemed to be such an obvious miss to me that there had
to be an obvious reason.
> 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?
- peter
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
