"use strict" VS setTimeout

Mark S. Miller erights at google.com
Mon Sep 8 15:49:55 PDT 2014

On Mon, Sep 8, 2014 at 3:15 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Thanks for the background history, however I am still not sold the fact
> it's a global object method should mean a global context should be passed.
> Following, a snippet simulating what would be my expectations
> ```js
> window.myTimer = function (callback, delay) {
>   // queue the callback as the task in delay milliseconds
>   // then in that future ...
>   callback(); // invoke such callback, that's it !
> };
> ```
> I wasn't expecting `setTimeout` or `setInterval` to be in charge of
> passing a context ... this looks to me as wrong as the old `([].sort)()`
> returning the global context, completely unexpected being not a
> matter/responsibility of that method.
> At least most of us agreed that's a potential implicit parameter leak but
> I am still sceptic the effort to fix it cross platform would be worth
> saving such leak.

Yeah, it sounds like we've all arrived at the same conclusion: This is
unlikely to get fixed, and so will remain a host provided API (browser and
node, incompatibly) rather than ever migrating into JS.

Let's just be sure that we avoid this mistake when promises grow something
like Q's Q.delay. Promise.delay? Promise.prototype.delay?

> Best Regards
> On Mon, Sep 8, 2014 at 10:38 PM, Brendan Eich <brendan at mozilla.org> wrote:
>> Mark Miller wrote:
>>> Yes, this is indeed the only question that Andrea and I are raising in
>>> this thread. As you acknowledge, providing window here is a little strange.
>>> I quibble with "a little". When a surprise surprises by providing less
>>> authority than expected, I don't much care. When the surprise is that more
>>> authority is provided than expected, that's a more serious issue.
>> In 1995-96, this wasn't surprising. Frames and framesets were there, also
>> window.open. Calling otherWindowOrFrame.setTimeout(func, delay, args)
>> worked by passing otherWindowOrFrame bound to |this| when invoking func.
>> (Er, only in 1996 -- setTimeout originally took a string as first
>> parameter and eval'ed it, no function variant.)
>> It is what it was :-P.
>> The surprise may be in thinking of sloppy-mode global functions as
>> |this|-free procedures, when they were rather global object methods.
>> Calling otherWindowOrFrame.func(args) bound |this| as you would expect, and
>> calling func in the context of otherWindowOrFrame bound the same |this|
>> value. Sloppy FTW :-P.
>> Agreed it is an implicit parameter capability leak. I'm just giving the
>> view as it was in the past, which is enshrined not only in sloppy mode as
>> you note, but in the spec for Window::setTimeout.
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/011da19d/attachment.html>

More information about the es-discuss mailing list