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

Re: [[Call]] behaviour of operations

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 22 Aug 2011 18:15:33 -0700
Cc: public-script-coord@w3.org
Message-Id: <7BB30F2E-4C59-4635-B9AD-0C7AFDFDA0AF@wirfs-brock.com>
To: Geoffrey Sneddon <gsneddon@opera.com>

On Jul 17, 2011, at 2:17 PM, Geoffrey Sneddon wrote:

> I can't find any definition of [[Call]] for operation functions. If it is intended to use the built-in definition, this should be specified, though this leads to a problem with the reference to 10.4.3 which checks whether the function is strict code or not (per ES5.1 host functions have no concept of strictness).

10.4.3 only applies to functions defined using ECMAScript code.  It does not apply to host functions or even to built-in native functions that aren't implemented using ECMAScript.

Host functions normally provide their own [[Call]] behavior.  The introduction to Chapter 15 says that "called as a function" behaviors in chapter 15 are the [[Call]] internal methods for the the corresponding built-ins.

> 
> At the moment, if the behaviour definition is used as [[Call]], then calls such as "alert('foo')" don't work, as the this value is undefined (and therefore ToObject will throw).

Note that all ES5 built-ins define their own thisArgument preprocessing (usually coercions) and don't rely on 10.4.3.  If alert or any other function wants to  access the global object based upon the observed thisValue (eg null or undefined) or any other flag then it needs to explicitly do it using whatever means of getting at the global object  that the function has available.

Allen





> 
> -- 
> Geoffrey Sneddon  Opera Software
> <http://gsnedders.com>
> <http://opera.com>
> 
Received on Tuesday, 23 August 2011 01:18:29 UTC

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