Shouldn't timers be specified?

Jorge jorge at jorgechamorro.com
Sun Jan 22 13:35:35 PST 2012


On 22/01/2012, at 21:00, Brendan Eich wrote:
>> Brandon Benvie <mailto:brandon at brandonbenvie.com>
>> January 21, 2012 9:59 PM
>> Sorry to spam this thread but I wanted to get the relevent points in up front:
>> 
>> 'Actually, wait a minute -- I think I disagree with you here.
> 
> On what? Being past the deadline? Not rushing a de-jure standard before we have synthesized the right semantics from relevant JS embeddings?
> 
>> Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed.
> 
> Why? What goes wrong if we go light on execution model one more time? I think nothing.
> 
> But in fact we are going to get a little more into execution model in ES6. How much remains to be seen. We discussed it at last week's meeting.
> 
> But this is not an all-or-nothing proposition, and I do not see the do-or-die requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. ES6 saying more doesn't alter these facts.

Now isn't that ~ the opposite of what you said on 2011-03-18 in David Bruants' "Bringing setTimeout to ECMAScript" thread ?

<quote>
Add to that the fact that Netscape and Microsoft failed, or chose not to, standardize the DOM level 0, and we have the current split where setTimeout is in HTML5 but the core language is embedded with increasing success in non-browser, no-DOM host environments *that want setTimeout*.

I'm open to Ecma TC39 absorbing setTimeout and the minimum machinery it entrains. We should ping Hixie.
</quote>

Why ?
What has changed ?

P.S.
Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order !
-- 
Jorge.


More information about the es-discuss mailing list