July TC39 meeting notes, day 1

Tom Van Cutsem tomvc.be at gmail.com
Fri Aug 12 07:51:53 PDT 2011

2011/8/12 David Bruant <david.bruant at labri.fr>

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

Except |get| and |set| also require the proxy itself. Passing |proxy| to
some traps and |prototype| to others complicates matters even more.

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

I see your point but still prefer the current API. |Proxy.create(handler,
proto)| makes it much clearer that |proto| is intended to be fixed at
creation time than requiring |handler| to define a non-writable data
property named "prototype".

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

More information about the es-discuss mailing list