On Aug 19, 2013, at 9:39 AM, Brandon Benvie wrote:
> On 8/19/2013 9:33 AM, Allen Wirfs-Brock wrote:
>> thisObj.[[Invoke]](propertyKey, function, argumentList)
>
> This could allow [[Invoke]] to trap `call` and `apply`, if propertyKey was
> allowed to be undefined.
I don't really want to get us off the topic WRT to the breaking change issue.
But, WRT call/apply here is a couple fragments from a private exchange between
TomVC and me:
> On Jul 30, 2013, at 9:57 AM, Allen Wirfs-Brock wrote:
>
>>
>> On Jul 30, 2013, at 1:25 AM, David Bruant wrote:
>>> ...
>>> This is not enough.
>>> this-binding ("proxy.getMonth()" when the target is a Date) is only half of
>>> the story. The other half remains unadressed
>>> ("Date.prototype.getMonth.call(proxy)"). Exotic objects aren't always used
>>> as "this" value. This is exactly Tom's feedback actually.
>>> We need the same solution for both cases (this and non-this usage of
>>> methods).
>>
>> I also raised this objection and it is what led to the recent update to the
>> virtual object API referenced above. What that change does is make it
>> easier for ES programmer to create proxies that behave in this manner.
>>
>> But, in the end we could not come up with a solution for the
>> Date.prototype.getMonth.call(proxy) issue. The [[Invoke]] MOP
>> operation/trap was added to minimize the actual occurrence of this scenario.
>> You can't use 'call' to force a built-in to operate upon the wrong kind of
>> object.
>>> ...
>
>>> Is there a handler semantics with which it can fully work? That's all is
>>> needed.
>>
>> The ForwardingHandler semantics is close to what you want. But it still
>> doesn't work the way you would like for direct "call" invocation or for
>> things like Array.isArray. The base issue for either of these is that they
>> don't indirect through the proxy handler and hence the handler doesn't have
>> an opportunity to replace the proxy reference with the target reference.
>
> I wonder if we could respecify F.p.call/apply in a manner that would make
> David's getMonth.call use case work (at least some of the time).
>
> [[Invoke]](P, ArgumentsList, Receiver) is current specified such that P must
> be a property key. What if we modify that so that P can be either a property
> key or a callable and that when a callable is passed the [[Get]] steps are
> skipped and P itself is used as the method.
>
> Then call/apply could be respecified in terms of [[Invoke]] and
> ForwardingHandler could do the appropriate handler substitution.
>
> Of course, this is only an asymptotically better solution, as it only
> improves the handler of Proxy objects in the this position. It wouldn't, may
> itself, fix Array.isArray.
>
Tom's thought were:
> On Jul 31, 2013, at 3:58 AM, Tom Van Cutsem wrote:
>
>> While clever, I don't think this will fly, for the reason that many
>> programmers use the explicit `call` syntax particularly so that they can
>> *guarantee* that the method to be invoked is the built-in that they
>> previously stashed away somewhere.
>>
>> If now `F.p.call` is going to delegate the decision of what code is to be
>> executed to the thisArg, that destroys the pattern.
>>
>> I know Mark's SES is full of preamble code where he first obtains references
>> to the actual built-ins, then invokes those built-ins using `call` to make
>> sure he will be executing only the original built-in code, nothing else.
These two ideas for [[Invoke]] could be combined (pass both 'f' and 'p' and
have call/apply use [[Invoke]]) but it still does't address Tom's concern.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
