W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: This binding and ES5 builtins

From: Oliver Hunt <oliver@apple.com>
Date: Thu, 07 Jul 2011 10:44:19 -0700
Cc: "Mark S. Miller" <erights@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "es5-discuss@mozilla.org" <es5-discuss@mozilla.org>
Message-id: <4E67EEA7-818B-4292-8F76-69D926B6654A@apple.com>
To: Luke Hoban <lukeh@microsoft.com>

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.  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.

No, the caller provided global is not web compatible -> type conversions (eg. primitive to Object equivalent, etc) are converted using what JSC terms the lexical global object: that is the global object in which a function is defined, this logically extends to |this| conversion.

It also means you can reason more about your code, take for example:

<global object1>
Number.prototype.times = function (f) { "use strict"; for (var i = 0; i < this; i++) f(); }
function imAwesome(count) {
    count.times(function(){alert("not cool")}
}

<global object2>
globalObject1.imAwesome(10);

If the callers global object was used for conversions the imAwesome function would not work.

--Oliver

>  
> Luke
>  
> From: es5-discuss-bounces@mozilla.org [mailto:es5-discuss-bounces@mozilla.org] On Behalf Of Mark S. Miller
> Sent: Thursday, July 07, 2011 9:07 AM
> To: Allen Wirfs-Brock
> Cc: public-script-coord@w3.org; es5-discuss@mozilla.org
> Subject: Re: {Spam?} Re: This binding and ES5 builtins
>  
> [+public-script-coord] as it is relevant to recent threads there.
> On Thu, Jul 7, 2011 at 3:20 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
>  
> On Jul 7, 2011, at 2:58 AM, Mark S. Miller wrote:
> 
> On Thu, Jul 7, 2011 at 7:40 AM, Brendan Eich <brendan@mozilla.org> wrote:
> [...]
> Where does ES5 stipulate that the [[Call]] internal method of built-in functions that are not constructors is exactly the steps in the algorithm for each built-in function, and not 13.2.1?
>  
> Good question. The spec should be clearer about that.
>  
>  
> Lasse's and Mark's interpretation of how calling built-in functions work is exactly the editorial intent.  This text:
>  
> This clause generally describes distinct behaviours for when a constructor is “called as a function” and for
> when it is “called as part of a new expression”. The “called as a function” behaviour corresponds to the
> invocation of the constructor’s [[Call]] internal method and the “called as part of a new expression” behaviour
> corresponds to the invocation of the constructor’s [[Construct]] internal method.
>  
> was also intended to mean that the [[Call]] internal methods of built-in-in functions are  exactly the behavior specified for the function in Clause 15.
>  
> The paragraph that precedes it probably needs to end with a sentence that says as much.  I'll add this as a 5.1 bug.
>  
> Relating this back to Luke's original question and setTimeout,  functions that are supplied by the host (regardless of whether you consider them to be host or native objects) must have [[Call]] and [[Construct]] behavior provided by the host as the 13.2.1 and 13.2.2 algorithms don't apply to them (as Lasse pointed out, at the very least they don't have [[Code]] internal properties that can be evaluated according to the rules of the specification).   Whether a single  [[Call]]/[[Construct]] behavior is common to all such host supplied functions or different for each is an implementation detail.
>  
> This means that such functions (or an intervening host supplied [[Call]] implementation) are presented with the actual this value that was either explicitly or implicitly provided at the call site without any preprocessing.  Undefined is passed as undefined, primitive values are passed as unwrapped primitive values, etc. If any conversion of an undefined this value to a global object is going to take place for such functions in must take place within the function (or or an intervening host supplied [[Call]] implementation).  The ES spec. does not define any communications path by which a call site would communicate its current global object (if any) to such a function.  So if a host supplied function is somehow converting this/undefined to the caller's global object it is doing something magical.  
>  
> Allen
>  
>  
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
>  
> _______________________________________________
> es5-discuss mailing list
> es5-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss
Received on Thursday, 7 July 2011 17:45:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC