[Proxies] Refactoring prototype climbing in the spec

[David Bruant]

Le 08/11/2011 11:54, Tom Van Cutsem a écrit :
>  
>
>     About [[SetP]]:
>     * It seems to me that we've traded a duplicated [[GetProperty]]
>     call for
>     a duplicated [[GetOwnProperty]] (Step 1 and 5.a) call on the receiver.
>     This could be avoided by storing the property descriptor at the
>     beginning (when O.[[setP]](Receiver, P, V) is called and O ===
>     receiver). Step 5.a could be remove by the change.
>
>
> The double [[GetOwnProperty]] invocation on the initial receiver
> should not be observable: if the initial Receiver of [[SetP]] is a
> proxy, the proxy's [[SetP]] algorithm (which triggers the "set" trap)
> executes instead of this algorithm.
Very true. And even if there is no trap, the default action is to
trigger [[Set]] on the target, so no duplicated call.

> (...)
>
> Long story short: the "O" variable in the [[SetP]] algorithm always
> denotes a normal non-proxy object. In general, the "Receiver" variable
> can be any object.
>  
>
>     * If step 5.a is removed, I think that step 5.b.i is useless,
>     because we
>     would have returned from the set when O was the receiver (by step
>     2.a of
>     [[setP]])
>     * If step 5.a is removed, then step 5.c is useless, because if the
>     desc
>     had a [[set]], then we would have already returned from one of the
>     substep of step 3 when O was the receiver
>
>     Why not redefining [[Get]] as what you have defined as [[GetP]] and
>     equivalent for [[Set]] and [[SetP]]?
>     Current 8.12.3 [[Get]] (P) would become [[Get]] (Receiver, P). It
>     would
>     be called with O as initial value for Receiver pretty much
>     everywhere in
>     the spec except within [[Get]] recursive calls.
>     Equivalent for [[Set]].
>     It would prevent the replacement of 2 Object.* methods by 2 others.
>
>
> The reason I introduced separate [[GetP]] and [[SetP]] methods is
> simply so that the "public API" of Objects remained intact. Your
> suggestion is reasonable: trade proliferation of built-in methods for
> a small public API change in the spec. I guess this is just a matter
> of find/replacing all the calls to [[Get]]/[[Put]].
Exactly, that's what I had in mind.

> Might even be an opportunity to get rid of "put" and use "set"
> consistently throughout the spec.
I cannot agree more with this idea. Especially with proxies having a
"set" trap and accessor properties having "setters", [[Put]] sounds
wrong even though that has been the name in ES5, ES3 (and even before?)

>
>     With the refactoring, on the direct proxy strawman, I don't think we
>     need the "proxy" argument for the get and set traps anymore. It
>     was here
>     as the receiver, but since we have the receiver itself, the get
>     and set
>     trap can just have the receiver and the target as argument.
>
>
> Good point. I'd wager that in most use cases, knowing that |receiver|
> is either your own proxy or a descendant of that proxy is
> sufficient. I can't currently think of a use case where the get/set
> trap would really want to be able to access the proxy itself, not just
> the proxy or a descendant.That doesn't mean that use cases for it
> don't exist, however.
Oh true, I thought that proxy and the receiver were the same objects but
if the proxy is on the prototype, it is not the case.

> I guess if access to the proxy is really needed, it's easy enough to
> accomplish:
>
> var p = Proxy.for(target, handler);
> handler.proxy = p;
Indeed.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111108/3ce9908e/attachment.html>