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 <[email protected]> Sent: 9/8/2014 5:08 To: Boris Zbarsky <[email protected]> Cc: es-discuss <[email protected]> Subject: Re: "use strict" VS setTimeout On Sun, Sep 7, 2014 at 6:35 PM, Boris Zbarsky <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
