2011/8/12 David Bruant <[email protected]> > 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". Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
