July TC39 meeting notes, day 1

Mark S. Miller erights at google.com
Fri Aug 12 07:15:31 PDT 2011

On Fri, Aug 12, 2011 at 5:23 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 12 August 2011 13:53, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> > I think I found a compelling and easy-to-understand
> > rule for determining whether or not a trap needs access to
> proxy/receiver:
> > if the trap deals with inherited properties, it needs access to |proxy|.
> >
> > Using that rule, the following traps require access to |proxy|:
> > get, set, getPropertyDescriptor, getPropertyNames, has, enumerate
> > (incidentally, all of these traps are or can be made derived)
> >
> > All other traps deal only with "own" properties, and do not need |proxy|:
> > getOwnPropertyDescriptor, getOwnPropertyNames, defineProperty, delete,
> fix,
> > hasOwn, keys
> Although that rule seems fairly simple, I still find a half/half
> situation unnecessarily confusing and error-prone. I would strongly
> vote for making the API consistent. That is, either equip all methods
> with a proxy argument (preferably as first), or none.

I agree, except for the "(preferably as first)". For me, this discussion has
successfully reconstructed the rationale for the strawman as it was,
including placing the parameter last. The reasons to put it last still
* To encourage its omission from parameter lists unless it is needed (the
rare case)
* To encourage that case to be rare, since touching the proxy during a trap
is surprisingly likely to lead to infinite regress unless great care is

+1 for the strawman as it was. Tom, apologies for forgetting this rationale
when presenting at the July meeting, delaying it all another two months.

> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110812/63ccdcc3/attachment.html>

More information about the es-discuss mailing list