Shouldn't timers be specified?

Rick Waldron waldron.rick at
Sun Jan 22 12:50:36 PST 2012

This is a perfect use case for the forth-coming module system (similar to
the way Globalization is being developed). Dave Herman and I had a brief
"over Twitter" exchange that began with my desire for a migration of
parseInt and parseFloat to Math, which I followed with a suggestion to do
the same with setTimeout and setInterval (despite those currently existing
in the realm of DOM APIs) to the imaginary Timer object.


On Sun, Jan 22, 2012 at 3:00 PM, Brendan Eich <brendan at> wrote:

> Brandon Benvie <mailto:brandon at brandonbenvie.**com<brandon at>
>> >
>> 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.
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list