- From: Geoffrey Sneddon <gsneddon@opera.com>
- Date: Mon, 29 Aug 2011 12:08:30 +0100
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org
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 <http://dev.w3.org/2006/webapi/WebIDL/#es-operations>: "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 <http://gsnedders.com> <http://opera.com>
Received on Monday, 29 August 2011 11:09:42 UTC