July TC39 meeting notes, day 1

David Bruant david.bruant at labri.fr
Fri Aug 12 05:13:21 PDT 2011


Le 12/08/2011 13:53, Tom Van Cutsem a écrit :
> 2011/8/11 Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>>
>
>
>     This seems to miss Sean's point that receiver is never other than
>     the proxy for get and set. That follows from how native object
>     [[Get]] works in ES5.
>
>
> You're right. Using the "get" trap as an example was silly, since it
> already has access to receiver, which is the proxy. Your comment made
> me revisit all derived traps again, and 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
>
> getPropertyDescriptor and getPropertyNames require access to |proxy|
> to walk the prototype-chain. The default behavior of get, set, has and
> enumerate is specified in terms of either or both of these traps, so
> they also need access to |proxy|. Note that get and set depend on
> |proxy| for two reasons: 1) to correctly set |this| for accessors, 2)
> to be able to lookup a property on the prototype chain
> (via |Object.getPropertyDescriptor(proxy, name)| )
If the reason access is given to the proxy is to give access to the
prototype, we could as well just give access to the prototype, couldn't we?

In the proxy API, the handler, prototype and call/construct traps are
all related to an internal property (things defined in ES5.1 - 8.6.2
http://es5.github.com/#x8.6.2)
What about passing one handler-like object with everything? This way,
all internals will be available in the argument. The API could be
reduced to Proxy.create(handler).
Regarding [[prototype]], handler.prototype could be just a initialzation
value for a copy of the handler, or handler.prototype could be imposed
to be a non-configurable, non-writable data property (TypeError if not
the case) which will not require to do a handler copy.
handler.call and handler.construct would have the rules that callTrap
and constructTrap have. And typeof Proxy.create(handler) === 'function'
<=> typeof handler.call === 'function' (to fit the ES5.1 definition of a
function)

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


More information about the es-discuss mailing list