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
> 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
> 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
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...
More information about the es-discuss