Re: [[Call]] behaviour of operations

On 24/08/11 00:20, Allen Wirfs-Brock wrote:
> On Aug 23, 2011, at 2:48 PM, Cameron McCormack wrote:
>> Otherwise I need to duplicate the native Function object internals [[FormalParameters]] and [[Code]] so that the 13.2.1 [[Call]] would work?  OK, I see that.
>> If we do change Window methods to bind to their original window object, then we could instead say that the values of the properties are Function objects that you'd get by calling .bind(<global>) on them.  Then we don't need to have any custom [[Call]] behaviour.
> Well you already have a [[Call]] method defined in 4.7.5.  However I think step 7 should be something like:
>     7 Invoke the [[Call]] internal method of the native or host function object that implements operation op with idlarg0..m−1 as the argument values and with the same this value.
> For, host object implemented functions the op [[Call]] method is simply the implementation of the specified operations.
> You probably also need to specify ECMAScript to WebIDL value conversions for the this value because call and apply permit any function to be called with arbitrary this values.

This is done in general for operations at 
<>: "If [the result 
of calling ToObject on the this value] is not a platform object that 
implements interface I, throw a TypeError", and similarly done for 
attribute getters/setters.

It would probably make more sense for [ImplicitThis] to be handled 
immediately prior to that, instead of redefining [[Call]] for it. (And 
would also thus be consistent with how it is normally handled in ES.)

> Normally for ES built-in functions any special processing of this values including converting undefined to the global object is part of the algorithmic specification of the function. You could use an extend attribute to to specify this processing conversions.  However, I'd be real careful about which functions you specify as automatically translating undefined to the Window object.  It probably makes sense for alert and probably some other functions but you really need to be selective or you risk ambient exposure of the global object.

In the majority of cases whether or not the this object is coerced will 
only be black-box observable because, e.g., foobar() would throw if 
foobar was not specified with [ImplicitThis] (as ToObject would throw).

> Also, ES consistency for such cases would use the global object of the context that the function originated in.

Having the same behaviour as built-in functions on the global object is 
probably worthwhile, though the only built-in function I can see on the 
global object that touches the global object at all is eval, and that's 
probably a bad thing to take lessons from. :)

Still, the idea in ES was to have callee-dependent this-coercion, which 
appears to be what WebIDL has now.

> Finally, keep in mind that in practice any ECMAScript native implementation of a WebIDL operation isn't going to actually have a [[Call]] internal method as defined in your 4.7.5.  Instead, it is going to be directly invoked using the ES5 13.2.1 [[Call]] it it is going to be up to the ECMAScript code within the function to do the work defined in 4.7.5 (include the overload dispatch).

Right, so to be consistent with ES built-ins, my suggestion would be 
simply to add a step 0 to the first list in #es-operations saying:

"If the interface on which the operation appears has an [ImplicitThis] 
extended attribute, and the this value is null or undefined, then let O 
be the ECMAScript global object associated with the Function object."

And change step 1 to start with "Otherwise,".

Geoffrey Sneddon — Opera Software

Received on Monday, 29 August 2011 11:09:42 UTC