July TC39 meeting notes, day 1

Kevin Reid kpreid at google.com
Fri Jul 29 17:42:59 PDT 2011


On Fri, Jul 29, 2011 at 15:20, Mark S. Miller <erights at google.com> wrote:
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.com>
> Date: Wed, Jul 27, 2011 at 9:21 PM
>
>
> == Handler access to proxies ==
[...]
> Conclusion: no rationale for adding a |proxy| parameter to all traps.
>
> == Proxy drop receiver ==
>
> Sean Eagan pointed out in
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-April/013916.html
>
> that the receiver parameter of Proxy handlers' get and set traps is useless,
> due to how these derived traps layer on fundamnetal traps.
>
> Conclusion: remove |receiver| from these traps.

Hi; Mark Miller asked me to post this. I am a developer working on
Google's Caja, writing ES5 code which uses proxies for our DOM
virtualization.

Suppose a proxy handler wishes to implement the 'set' or 'get' trap in
a way similar but not identical to the derived trap — similar in that
it obtains a property descriptor (from the getOwnPropertyDescriptor
trap or otherwise) and proceeds according to the contents of the
descriptor.

If the property being accessed is an accessor property, then the
descriptor's 'get' or 'set' function should be invoked, *with 'this'
being the proxy*. This behavior cannot be implemented purely within
the handler object (i.e. without the explicit cooperation of the code
calling Proxy.create) unless the proxy is passed to the handler.

I consider it a useful principle that it should be possible for an
object with a given method (the get/set trap of the handler, here) to
implement the same behavior as will be performed by the caller (Proxy)
if that method did not exist (the derived trap); therefore, I
recommend that the 'get' and 'set' traps should have a parameter which
is the proxy.

I have no position on whether the proxy parameter should be first or
last, or whether other traps should have one.

-- 
Kevin Reid
(Google intern)
<http://switchb.org/kpreid/>


More information about the es-discuss mailing list