"use strict" VS setTimeout

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Sep 8 00:50:14 PDT 2014


I wonder what was breaking, specially after showing there were
inconsistencies between browsers. Yet nobody wrote a use case where a dev
explicitly marks a callback as strict **expecting** to receive a global
context in it once passed without bind to a setTimeout or setInterval ...
Anyway, thanks for the heads up on the failing experiment. Curious to know
if ES5 at that time was popular.

Regards

Sent from my Windows Phone
------------------------------
From: Mark S. Miller <erights at google.com>
Sent: ‎9/‎8/‎2014 5:08
To: Boris Zbarsky <bzbarsky at mit.edu>
Cc: es-discuss <es-discuss at mozilla.org>
Subject: Re: "use strict" VS setTimeout

On Sun, Sep 7, 2014 at 6:35 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
>
>> I know this is probably W3C land but the following code shows the global
>> object
>>
>
> Careful with your use of the word "the".  Your ES5-centric assumptions are
> showing.  ;)
>
> The function passed to setTimeout will be invoked with "this" set to the
> window that was the "this" of the setTimeout call.  Note that setTimeout
> itself is a sloppy function for historicaly reasons, which is why it has a
> non-undefined "this" even if called as a bareword.
>
> Now, and here's where I have a problem with your use of "the": the Window
> that setTimeout is invoked on is NOT necessarily the same as the global
> object of the function.  And the web totally depends (or at least depended
> a few years ago) on not getting the global object of the function, but
> rather the Window setTimeout was called on as the "this" in the callback.
> We tried changing that at one point in Gecko as an experiment, and websites
> broke.



This is the crucial experiment. That negative result probably kills the
possibility of the improvement we're discussing. Too bad, but better to
know early. Thanks.



>
>
>  This looks like a potential problem when possible passed methods are not
>> bound + it looks inconsistent with *"use strict"* expectations.
>>
>
> If your expectations include "never called via .call() with an explicit
> 'this' passed in", then the expectations might need adjusting.


I think this still misses the point. *Given* that we understand the purpose
of setTimeout etc to be postponing action, it is surprising for setTimeout
to provide any global object to the callback. Since it does,
a) we need to find a way to explain setTimeout etc so that this is not
surprising, and
b) we need safe alternatives to setTimeout etc that only postpones, perhaps
like Q.delay.


No one is saying that it is always surprising for a strict function to be
called with a this-binding other than undefined. Indeed, this is necessary
for strict functions used as conventional methods.


>
> -Boris
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/77b9c0c2/attachment-0001.html>


More information about the es-discuss mailing list