July TC39 meeting notes, day 1

Brendan Eich brendan at mozilla.com
Thu Aug 4 10:34:55 PDT 2011

On Jul 31, 2011, at 1:04 PM, Sean Eagan wrote:

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

Ok, right -- even without the extra proxy parameter in addition to receiver, dropping receiver makes sense. Sorry to go in a circle on this.

It's a trap API change, and I agree with Mark that we need Tom to bless it.

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

There is a downside, Mark noted it in the meeting: touching the proxy is highly likely to diverge in runaway recursion.

>  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