Adding [[Invoke]] to address issues with methods called on Proxies

Mark S. Miller erights at google.com
Tue Jan 29 11:14:26 PST 2013


On Tue, Jan 29, 2013 at 10:52 AM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Brandon Benvie wrote:
>
>> Responding in this thread since it's a more appropriate place.
>>
>> 1.) It complicates the object model, in that it adds a new internal
>> method to objects, but it also clarifies it. It falls under the same
>> category as [[GetP]] and [[SetP]]: they complicate the object model, but
>> they also clarify it and they are only observable to Proxies. All three
>> are only observable to Proxies. Proxies are the thing that ultimately
>> complicates the object model and these are fallout from it, but most of
>> us agree that Proxies are worth it.
>>
>
> Again, why add something that is "only observable to Proxies"? It is an
> exception, and it bring much more complication than straight rule. Such an
> exception is future-unfriendly.
>
> And I do not agree that it clarifies the object model. On the contrary. It
> makes it inconsistent.
>
>   var quux = foo.bar;
>   quux.call(foo, baz);
>
> was always equivalent of foo.bar(baz). Now, it is not.
>
> [[CallProperty]] is bad because it is alternative to [[Get]], in certain
> situations. What is the problem with, instead, doing it (imo) more
> properly, by reifying [[ChooseThis]](receiver, property) or something
> similar?


Hi Herby,

Perhaps I missed it, but could you expand on the [[ChooseThis]] idea? Or
provide a link to an earlier discussion if it's already adequately covered?
Thanks.




> This will not break the above equivalence, since it will be present in all
> oop calls and inside .apply and .call as well.
>
>
>  2.) The abstract method Invoke already exists in the spec. This is a
>> thing that the ES6 spec, with its deferring to prototypal inheritance
>> for some things previously limited to internal properties, needs. Adding
>> [[CallProperty]] would probably be a near net-zero change (perhaps a
>> net-reduction) in total spec complexity, since Invoke already exists in
>> the spec and is largely subsumed by [[CallProperty]].
>>
>
> Special case adds more complexity than extract (imo).
> Spec efficiency does not beat complicating semantics.
>
>  On Tue, Jan 29, 2013 at 12:56 PM, Herby Vojčík <herby at mailbox.sk
>> <mailto:herby at mailbox.sk>> wrote:
>>
>>
>>
>>     Brandon Benvie wrote:
>>
>>         To elaborate, I've realized that my main disagreement with your
>>         position
>>         (really my care at all with the private discussion) is much better
>>         solved by introducing [[CallProperty]]. That is: Proxies currently
>>
>>
>>     ... and complicates object model. My main problem with
>>     [[CallProperty]] is the discrepancy between [[Get]] (used in
>>     [[Get]]+[[Call]]) and [[CallProperty]] (my assumption that by
>>     [[CallProperty]] you mean operation that replaces [[Get]]+[[Call]]).
>>
>>     I'd solve it otherwise. Let's say that foo.bar(baz) is split to
>>     _three_ operations: [[Get]]+[[OopBind]]+[[Call]], where [[OopBind]]
>>     resolves this. Then, proxies should only be able to trap [[OopBind]]
>>     (but it will still be the same combination, involving trappable
>>     [[Get]] at the beginning and ending with (direct) [[Call]]).
>>
>>
>>         handle |this| binding of method calls very poorly. I'm all for
>>         either
>>         removing private or making it *really* private, but Proxies are
>>         basically worthless in the private middleground which causes them
>> to
>>         break half the time in ES6 code. But [[CallProperty]] fixes the
>>         issue in
>>         a way that seems acceptable to all parties.
>>
>>
>>     Herby
>>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130129/01bf71f5/attachment-0001.html>


More information about the es-discuss mailing list