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

Re: [[Call]] behaviour of operations

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 22 Aug 2011 11:19:03 +1200
Message-ID: <4E519267.3030505@mcc.id.au>
To: Geoffrey Sneddon <gsneddon@opera.com>
CC: public-script-coord@w3.org
Hi Geoffrey.

Thanks for your comment.

On 18/07/11 9:17 AM, 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).
> 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).

I have added an extended attribute [ImplicitThis] which is to be used on 
the Window interface.  This causes the Function objects for operations 
on the interface to use the global object as the this value even if null 
or undefined is passed in from strict mode code.  This is done in a new 
definition for [[Call]] for Function objects in #es-operations.

The new [[Call]] delegates to the default [[Call]].  I don't think 
there's a problem with there being no concept of strictness for host 
functions -- they just won't be strict.


Can you please indicate whether the above resolution is acceptable for 
the Disposition of Comments document I'll have to prepare.


Received on Sunday, 21 August 2011 23:19:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC