On Thu, Jul 7, 2011 at 12:14 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> Allen Wirfs-Brock:
> > Did you mean:
> > (function() {"use strict"; return this}).call(undefined)
>
> Yeah, I guess I did, thanks. (I looked quickly at the description of
> Function.prototype.call and figured that the this value given to
> [[Call]] was used unconditionally as the value of `this`, but of course
> the “Entering Function Code” section of the spec does do the strict mode
> check. I think I assumed `func.call(undefined)` would be different from
> `func()` even in non-strict mode.)
>
> I also just realised that the checking of the this value that Boris
> quoted will need to be tweaked so that static operations don’t throw.
>
> Doesn’t setTimeout need to know which window object it is called on, so
> that the right task queue is used? (I guess that could be encoded into
> the Window.prototype.setTimeout Function object, since there’ll only be
> one window object per setTimeout Function anyway.)
>
Exactly. It makes a difference. Should
window1.setTimeout.call(window2, ...)
use window1's or window2's task queue? I think it should use window1's,
i.e., a given setTimeout function should already as-if-lexically capture the
task queue of it birth environment and ignore its this-binding.
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
>
--
Cheers,
--MarkM