- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Mon, 22 Aug 2011 18:26:20 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Geoffrey Sneddon <gsneddon@opera.com>, public-script-coord@w3.org
On Aug 21, 2011, at 4:19 PM, Cameron McCormack wrote:
> 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.
You can only do that delegation if the function is implemented in ES! 13.2.1 only applies functions defined in actual ECAMScript source code
>
> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html.diff?r1=1.347;r2=1.348;f=h
>
> Can you please indicate whether the above resolution is acceptable for the Disposition of Comments document I'll have to prepare.
>
> Thanks,
>
> Cameron
>
Received on Tuesday, 23 August 2011 01:27:12 UTC