Le 19/04/2011 21:33, Sean Eagan a écrit : > On Mon, Apr 18, 2011 at 7:38 PM, David Bruant <[email protected]> wrote: >>> Thus, it seems to me that storing >>> anything in handlers besides existing traps is likely to cause future >>> headaches, and should be avoided. >> That's an excellent point. It sounds to be a safe idea to consider the >> handler as a namespace used for traps and that anything internal >> state-related should be captured. >> On the other hand, the main advantage of having "this.target" is that >> anyone can replace one trap with user JS code (to add a logger for >> instance) and have a way to access the target anyway. This would be >> impossible if the target was encapsulated and only accessible within >> built-in traps scopes. This advantage extends to any proxy library that >> would decide to expose its handler and partial internal state by >> exposing the partial state on the handler object. > None of this is an issue in the API I am proposing, since the state is > passed to each trap, not captured from the scope. You are perfectly right.
>> Unless we consider generalizing "this.getTarget" to any use case by >> having a "this.getState" method (it's not a trap) on handlers. It would >> be used when there is a need to standardize the state of the proxy >> library (like the "target" for forwarding proxies). It would be reserved >> for proxy library authors who would like to expose their handlers with >> in mind the idea that people would change traps while still being able >> to access partial internal state. Actually a |this.state| weak map >> should be enough. > Here are the reasons why I believe the API I am proposing is superior > to a weak map implementation: Just to clarify, a weak map was just an example. If this.state is an accessor or if there is a .getState method, I'm fine with it. > Code simplicity: > Can reference proxy state via |state| which is much shorter than > |this.state.get(proxy)| or |this.getState(proxy)| > No proxy-assocation code needed, so avoids the complexities of > "ForwardingPair" from your example. (...) >> This constraint would change the way forwarding proxies are created >> since the proxy object identity would need to be known before >> initializing the state. > This is not an issue in the API I am proposing, as it abstracts the > proxy-state association process via the "create" trap. I'll give you this point. (both are very close, that's why I comment them together) > Interoperability: > Standardized and abstract proxy-state association mechanism, > handlers do not need to coordinate how to do this. > > Safety: > No "state" or "getState" property needed on handler, so completely > avoids trap namespace pollution If only one "state" or "getState" property is standardized, then, there is no pollution. There is one available thing that is available for people to use, everyone is encouraged to use it and if they don't and use their own names, then, they'll end up having collisions, but at least, they would have been provided a standardized mechanism, so they cannot accuse the spec for not taking care of their use case. > Less infinite recursion hazard as there is no need to use the proxy > reference to get to the state The weak map idea associate the state with the proxy object identity. There should be no recursion hazard. Your state argument would be based on object identity too; the difference between our two ideas is that you're using internal mechanisms while I explicit the state exposure. To be honest, right now, I think that both ideas are good and am unable to say which is better yet. > Performance: > Avoid weak map lookups, derived traps and traps that call inherited > traps could have arbitrarily many of these as there is no mechanism to > pass state to traps Performance should never be an argument unless we're talking about asymptotic complexity in space or time. Implementations optimizations come and go. A weak map lookup may be better optimize thanks to static analysis or type inference in some cases. No one can tell. > Also, if for any reason a given handler author did not want to use the > native proxy state support, preferring to implement this on their own > (such as by using WeakMap's), then we could potentially provide an opt > out mechanism of just not defining a "create" trap. For these > handlers, the implementation would not store any proxy state, and > could even omit the state argument when calling its traps (or just > pass undefined). For the matter of comparison, with "state"/"getState" handler property, not having the property would be an opt-out, so both ideas are even on the topic from what I see. >> Hence we would probably need to do something >> like: https://gist.github.com/926581 > Here's what the same functionality would look like in the API I am proposing: > > https://gist.github.com/929185 That's interesting. I agree with what Tom said in some reply about "getPrototypeOf". The name is confusing, but the point is good. Why not just having a prototype property? David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
