"use strict" VS setTimeout

Mark Miller erights at gmail.com
Mon Sep 8 07:40:32 PDT 2014


On Mon, Sep 8, 2014 at 7:25 AM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Apologies, now I see what you meant and I think option 2 would be probably
> ideal.
>

I disagree. I think option #2 is rather horrible. Strictness can't be
tested in JS user code, and shouldn't be. And sloppy functions can't be
emulated by proxies, and shouldn't be. Whatever we spec as the caller's
interaction with the callee, it shouldn't be predicated on "if the callee
is strict....". We've taken pains to avoid this everywhere else[*].

The status quo, though we agree on the pain it causes, is less painful than
introducing this conditional.


[*] SloppyFunction.caller must not reveal a strict function. This means
that calling into a sloppy function can reveal whether the caller is strict
-- but only if the sloppy function has the legacy magic caller property and
calls a sloppy function.



> 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:
>
> requestAnimationFrame
> setInterval
> setTimeout
>
> 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.
>
> Best Regards
>
>
> 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, <
>> http://fiddle.jshell.net/tmt5e9m6/2/show/>.
>>
>> 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.
>>
>> -Boris
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Text by me above is hereby placed in the public domain

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


More information about the es-discuss mailing list