Shouldn't timers be specified?
waldron.rick at gmail.com
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 mozilla.org> wrote:
> Brandon Benvie <mailto:brandon at brandonbenvie.**com<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
>> '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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss