[Proxies] Refactoring prototype climbing in the spec

David Bruant bruant.d at gmail.com
Mon Nov 7 13:54:36 PST 2011

Hi Tom,

Thanks for all this work!

Le 07/11/2011 16:54, Tom Van Cutsem a écrit :
> Hi,
> I wrote up an initial (but fairly complete) draft of a proposed
> refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms
> to change the way in which these algorithms climb the prototype
> chain: <http://wiki.ecmascript.org/doku.php?id=strawman:refactoring_put>
> This is mainly beneficial for proxies, as the prototype walking
> strategy becomes observable to proxies-used-as-prototypes.
> IMHO, the refactored algorithms interoperate with proxies in a much
> saner way, finally restoring the intuitive semantics of the "get" and
> "set" traps that MarkM and I had in mind from the beginning, but which
> Sean Eagan pointed out were flawed given the ES5 spec algorithms.
I am a big fan of this refactoring.
I like the idea that the algorithm transfers full control to the proxy.
Also, accepting this strawman would solve my inherited event properties
problem because I would have access to the receiver from the get trap
and would be able to do the binding I want.

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.
* 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
* 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.

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.


More information about the es-discuss mailing list