July TC39 meeting notes, day 1

Sean Eagan seaneagan1 at gmail.com
Sun Jul 31 13:04:46 PDT 2011


A 'receiver' argument is not needed because it would never be
different than the proxy, and the proxy can either be passed as an
argument or stored either as an own property of the handler, or as a
value keyed by the handler in a weak map, which there seems to have
been TC39 concensus on.

Regarding whether or not a proxy argument should be added, there do
seem to be advantages to passing the proxy as an argument, but I don't
feel particularly strong about it.  I do however feel strongly that a
'proxy' argument should not be added selectively to just the 'get' and
'set' trap, or any other limited set of traps.  There are surely use
cases for accessing the proxy within all traps, so for consistency's
sake it seems the method for accessing the proxy should be the same
across all traps.

On Fri, Jul 29, 2011 at 8:13 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jul 29, 2011, at 5:42 PM, Kevin Reid wrote:
>
>> 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.
>
> Thanks, you caught a blatant inconsistency in our reasoning. We used Sean's message (linked above) as a reason to remove receiver, that Sean wrote that message assuming both proxy and receiver would be parameters to get and set traps. Sean demonstrated that the two parameters would always have the same value, ergo only one was needed, and since at that time, proxy was considered important to keep (and add to all traps), receiver fell under the ax.
>
> But as noted higher above, at this week's meeting, we rejected adding proxy to all traps, including get and set. Therefore we must keep the receiver parameter of those two traps, for the reasons you give. Thanks again!
>
> /be
>
>
>>
>> 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/>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Sean Eagan


More information about the es-discuss mailing list