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