On Fri, Aug 12, 2011 at 07:51, Tom Van Cutsem <[email protected]> wrote:
> 2011/8/12 David Bruant <[email protected]> > >> 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". > This reminds me of what I did in my revision of the E proxy API. If it were to be the case that the proxy is completely defined by a single handler, then it would be (less im)plausible to have it be the case that Proxy.create(handler) === Proxy.create(handler) That is, a proxy's *identity* is fully specified by its parameters, the handler. In the E context this has benefits for our equality semantics and garbage collection. If this were the case in JavaScript, it would mean that traps would never need a proxy parameter, because Proxy.create(this) would substitute for it. (The handler methods in E indeed don't get the proxy as a parameter.) You probably don't want to do this, but the observation was interesting to me.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
