Proxies: wrong "receiver" used in default "set" trap

Andreas Rossberg rossberg at
Fri Dec 21 05:15:39 PST 2012

On 21 December 2012 03:00, Allen Wirfs-Brock <allen at> wrote:

> On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
> I'm not sure I follow. In my understanding, the original Receiver is only
> needed for traps that involve prototype-chain walking and are thus
> |this|-sensitive. That would be just [[GetP]] and [[SetP]]. One can make
> the case (David has done so in the past) for [[HasProperty]] and
> [[Enumerate]] since they also walk the proto-chain, although it's not
> strictly necessary as the language currently does not make these operations
> |this|-sensitive.
> The proxy target delegation chain is also this-sensitive when it invokes
> internal methods.  For example, in the revised [[SetP]] step 5 it is
> important  that the [[DefineOwnProperty]] calls (in 5.e..ii and indirectly
> in 5.f.i are made on Receiver and not O.
> [...]
> If you step back a bit and just think about the concepts of Lieberman
> delegation and self-calls without worry about the specific of the proxies
> or the ES MOP I think you will come to see that delegated target calls
> naturally should self-call back to the original object.  That's what
> Lieberman style delegation is all about.

While I agree with your line of reasoning in principle, it seems that your
proposed change imposes substantial complications on implementations. While
simple forwarding of missing traps allows reusing existing code for
performing the respective operations (including all sorts of optimisations
and special-casing), it seems to me that a delegation semantics requires
duplicating much of the core functionality of objects to correctly deal
with the rare case where the object is a proxy target.

So far, proxies where mainly a special case implementations could
distinguish early on, and not care about them in the rest of the logic for
a given operation (except where you had to do proto climbing). With
delegation semantics everywhere, that is no longer the case, and everything
becomes intertwined.

If a VM is no longer able to reuse existing optimisations easily for the
proxy case, my guess is that such a semantics would make direct proxies
significantly slower in practice. I, for one, would not look forward to
implementing the change, let alone optimising it. :)

That said, I normally stand on the side of a better semantics. But we
should be aware of the likely implications in this case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list