"use strict" VS setTimeout
andrea.giammarchi at gmail.com
Mon Sep 8 07:25:23 PDT 2014
Apologies, now I see what you meant and I think option 2 would be probably
ideal. ES5+ engines can easily retrieve "strictness" so while it might seem
weird it would surprise less, syntax and explicit intent speaking, and will
remove the right to pass *a* global context to the callback.
Going through the list of all properties it looks like at the end of the
day only things to improve/change are:
Although I have honestly no idea how to explain via W3C pages that JS might
be strict or not ... seems to me that "_strictness_" should be outside the
DOM knowledge so .... probably this should be part of ES specification.
However, it seems at this point an overly-complicated tiny little change
full of cross-web alignment that might not even have a concrete impact in
the real world ... so maybe all this won't be worth to fix.
Thanks all for thoughts, hints, and insights on this matter.
On Mon, Sep 8, 2014 at 2:45 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 9/8/14, 8:15 AM, Andrea Giammarchi wrote:
>> no introspection or nothing magic and weird, simply `.call(undefined)`
>> would do for sloppy and strict, preserving global in sloppy, avoiding
>> shenanigans in strict.
> You seem to be assuming there is only one global involved again. Did you
> look at my testcase I posted earlier in this thread? Again, <
> The behavior that testcase shows is not achievable by doing
> .call(undefined). If the web depends on that behavior (which is worth
> verifying if someone wants to experiment!), then we can't blindly do
> .call(undefined). Even if that is case, we _could_ still do
> .call(undefined) when the callee is strict, since I'm fairly certain the
> web does not depend on that behavior for strict callees, but that involves
> introspecting the strictness of the callee.
> So we have three options, as I see it:
> 1) Keep existing behavior; always pass in a "this" value that's the
> window that was the "this" of the setTimeout call.
> 2) Change behavior for strict callees only. This involves introspecting
> the strictness of the callee, which is clearly doable in implementations,
> but weird and magical from the ES point of view.
> 3) Change behavior across the board to passing undefined as the this
> value, and deal with any resulting compat issues via evangelism.
> Hence my curiosity: when this experiment was made, which code with `"use
>> strict"` failed ?
> This only matters for option 2 above, right? The compat constraints for
> option 3 are all around sloppy functions, which is what most people use
> today. That's why I even brought up option 2: the question you were asking
> was presupposing that this option should be on the table.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss