Hi David, 2011/8/14 David Bruant <[email protected]>
> We have identified that |proxy| could be used to retrieve the prototype. > What other "useful" information could be retrieved from |proxy|? > Its [[Prototype]], its [[Class]], its identity (as |this| for > getters/setters in get/set traps and as WeakMap key, however this has never > had a lot of support on es-discuss)? > [[call]] would be accessible via proxy() or proxy.call() > [[construct]] would be accessible via new proxy() > All other internal things seem accessible via the handler (|this| from > within a handler method context). > Maybe that there is another dimension of inconsistency which is that > internal properties and methods can be accessed via two things: the handler > and the proxy. > I really would not call this an inconsistency. This is really a consequence of the original design, i.e. the fact that we separate proxy from handler: that introduces an "application-level" entry point (the proxy), and a "meta-level" entry point (the handler). > "two things"... rather than one (the handler) as it was originally. > Hence my previous e-mail about bringing everything back to the handler > (prototype, call, construct, etc.) > > Also, it's a bit strange that all traps can be changed dynamically while > call and construct can't. Well, that's not entirely true: call and construct > could contain some context in a closure that could change their behavior > over time. > Your arguments to put |call| and |construct| in the handler are reasonable. I think that can be done. I recall we decided against it earlier, as it makes the |handler| reusable across both object and function proxies (they have the exact same API). However, passing a |handler| with call and construct traps to an object proxy should be fine. There would be some consequences though: handler functions are currently "methods" that are invoked with |this| bound to the handler. Not so with the call and construct trap (which are thought of as functions and have |this| bound to undefined). Also, fixing a function proxy requires a change: the fix() trap should then also return a fixed call and construct trap to use, in addition to the property map (cf. an earlier proposal: < http://wiki.ecmascript.org/doku.php?id=strawman:uniform_proxies>). That is a pity because now the fix() trap is no longer uniform across object/function proxies. From what I hear from VM implementors, the current distinction between object/function proxies aligns well with the fixing process. As for [[Prototype]], [[Class]], identity: I much prefer our current design guideline, which is that any information that is supposed to be stable/fixed is better passed as a separate argument to Proxy.create{Function}, rather than either being queried once from the handler, or requiring the handler to provide it via a non-writable, non-configurable data property. Passing |proxy| as an argument to at least the inheritance-related traps seems to cover all of the use cases we came up with thus far. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
