Re: This binding and ES5 builtins

On Jul 7, 2011, at 11:05 AM, Brendan Eich wrote:

> On Jul 7, 2011, at 10:33 AM, Luke Hoban wrote:
>>  Also, the note that “if a host supplied function is somehow converting this/undefined to the caller's global object it is doing something magical”, is concerning.  As far as I understand, with multiple globals, the web-compatible behaviour is to pass the caller-side global.
> 
> No! Ah, I see Oliver replied.
> 
> The situation with caller-side |this| computation in non-strict global code is not to pass null or undefined and then replace that with the dynamic scope's global object. Rather, property lookup computes a Reference for the unqualified global property name used as the callee expression, and that Reference base is the exactly the global object in which the global property was found.
> 
> This is lexical not dynamic scope, in the caller evaluation context. It predates ES5 and it cannot be modeled with callee-based |this| rectification. It's why we did not "fix" https://bugzilla.mozilla.org/show_bug.cgi?id=634590 is Firefox 4.

And if the host callable object is invoked by a funny expression, e.g.

(1, hostCallable)();

and it's a built-in, then ES3 + reality would indeed pass null for |this| in the CallExpression semantics, and (here's where ES3 dropped the ball) the real-world implementations would fall back *not* on the dynamic scope's global object, but on hostCallable's global.

This relied on even built-ins and host callables having a link to their global, parallel to [[Scope]] for user-defined functions.

You can contrive a test case where the dynamic scope's global is not the same, by borrowing hostCallable from another window or frame.

This is still unspecified in ECMA-262 because we haven't specified multiple globals.

/be