"use strict" VS setTimeout
erights at gmail.com
Sun Sep 7 11:48:32 PDT 2014
On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:
> I don't understand why this is any more surprising than any other
> function that calls its callback with .call(something).
The issue is what the something should be, and which choices for something
are surprising for what APIs.
> It doesn't matter whether the callback is strict or not; .call(window),
> which is what the spec does, will override it.
I don't understand what you're trying to say here. What will override what?
> As far as I can see this issue has absolutely nothing to do with strict
> vs. sloppy.
As Andrea initially stated, this is a DOM-spec issue, not a JS issue, in
that JS allows setTimeout to call the callback with WTF it wants. However,
the purpose of setTimeout, etc, from the JS programmer's perspective, is to
postpone some action to some future time. From this understanding, there's
no reason to give the postponed action access to the global object. From a
POLA perspective, there is thus strong reason not to.
Put another way, were the functionality of setTimeout etc only to postpone
calling its callback, and not to provide it access to the global object,
then we might consider moving it from the W3C side to the JS side, like we
did for promises. After all, this temporal postponement function, by
itself, would seem equally useful in non-browser contexts, like Node.
Speaking of which:
On Sun, Sep 7, 2014 at 11:35 AM, Alex Kocharin <alex at kocharin.ru> wrote:
> I would add that in node.js it returns neither undefined nor window, but a
> timer object, which you can clear up with `clearInterval(this)` inside the
Since these are specced only for the browser, this divergent behavior
doesn't violate anything. Were setTimeout etc to be moved from W3C to JS,
we would not pass the global object, so again you would not be violating
the spec *by virtue of* not passing the global object.
However, in order to not break the web, as was pointed out, any such
possible future JS std setTimeout etc would only pass undefined, so that
sloppy functions still see their global object. So in that sense, this node
behavior is incompatible with any behavior that could be standardized by a
future JS for setTimeout etc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss