Re: This binding and ES5 builtins

On Jul 7, 2011, at 10:33 AM, Luke Hoban wrote:

> Interesting – this is not what I expected.  That interpretation implies that ES5 intentionally diverged from the behaviour that has been standard in all major browsers (until some starting changing recently) as far as I can tell.  Has there been previous discussion of the compatibility implications?
>  
Yes, this was intentional.  Historically, browsers passed the global object into built-ins called with undefined/null this value. In some cases that could be exploited to leak the global object. We intentionally made breaking change to close those cases. This was all discussed during the development of ES5. 


> Note that for the original two test cases, here is the results I see – which seems to offer historical (and current) support for the alternative interpretation:
>  
> >> (1, Object.prototype.hasOwnProperty)('abc')
> IE6: false, IE9: false, IE10: false, FF3: false, FF4: TypeError, Chrome13: false, Chrome14: false, Safari5: false, Opera11: false
>  
> >>  var f = Object.prototype.hasOwnProperty
> >>  f('abc')
> IE6: false, IE9: false, IE10: false, FF3: false, FF4: TypeError, Chrome13: false, Chrome14: TypeError, Safari5: false, Opera11: false
>  
> Saying that undefined should be passed to built-ins feels like it is strict mode bleeding out of the strict mode opt-in.  In non-strict, in practice, the “global object” (leaving aside multiple globals for now) is passed as this to unbound function calls, irrespective of whether they are native, built-in or host functions.  Why is this being changed to undefined outside of strict mode?

Built-ins are neither strict nor non-strict functions.  They are simply built-ins.  ES5 tries to tame ambient access to the global object.  In order to accomplish this more than just strict mode was required.  It also required making sure that the built-ins also did not leak this.

>  
> I would expect that if 13.2.1 is not relevant to built-ins, then the built-ins should have some other spec section that accomplishes the relevant parts of 13.2.1, in particular, the this-binding fix-up. 

13.2.1 isn't relevant to built-ins. There are no relevant parts of 13.2.1 that need to be accomplished elsewhere. Built-ins are their own [[Call]] and they simply receive the arguments (including the original this value) of [[Call]].  

>  
> 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.  Pushing the burden of managing this to something magical the host functions need to take care of feels like the wrong direction, given what standard practice appears to have been.

I think oliver adequately addressed this

Allen