evaluation order and the [[Invoke]] MOP operation

Tom Van Cutsem tomvc.be at gmail.com
Tue Aug 27 03:37:12 PDT 2013


(Pardon the late reply. Catching up.)

I'd also go with option 1 (accept that [[Invoke]] changes visible order of
side-effects).

Option 2 pollutes the simple interface of [[Invoke]] for compatibility with
edge-cases, which, as MarkM points out, are not fully web-compatible anyway.
The symmetric operation, i.e. Reflect.invoke(obj, "m", f, args) would also
make little sense.

Regards,
Tom


2013/8/19 Mark S. Miller <erights at google.com>

> And because it remains open, whereas FF, Safari, and old Opera followed
> ES5, the cross-browser web must be compatible with either decision.
>
>
> On Mon, Aug 19, 2013 at 11:15 AM, Mark S. Miller <erights at google.com>wrote:
>
>> More data about whether changing this would break anything:
>>
>> I reported <https://code.google.com/p/v8/issues/detail?id=691> in May
>> 2010. It remains open -- probably because it has caused few actual problems.
>>
>>
>> On Mon, Aug 19, 2013 at 10:44 AM, Allen Wirfs-Brock <
>> allen at wirfs-brock.com> wrote:
>>
>>>
>>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130827/7d5ffb7b/attachment-0001.html>


More information about the es-discuss mailing list