Shouldn't timers be specified?

Rick Waldron 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.

Rick



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
>> 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 mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120122/cb4df2b3/attachment-0001.html>


More information about the es-discuss mailing list