Le 18/04/2011 21:55, Sean Eagan a écrit : > Storing proxy instance state directly within handlers: > ============================================================== > > Trap namespace pollution: > > The default handler, Proxy.Handler, stores proxy instance state > directly in each handler's "target" property. Notice that this > immediately prevents a "target" trap from being added in the future, > which of course isn't so bad as it is an unlikely future trap name. > However, as soon as proxies are standardized and start to be used, if > user defined proxy instance state is allowed (and even strongly > encouraged by implementing Proxy.Handler this way) to be stored in > handlers, the entire remainder of the trap namespace will be open to > pollution, and thus prevent *any* new traps from being added in the > future without the likelihood of breaking existing code. Beyond proxy > instance state, users may also add helper methods including perceived > "missing" traps, which may directly correlate to traps that would be > wanted to be added in the future. 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.
As a side note, I'd like to say that, in my opinion, Proxy.Handler is a misleading name. It seems to imply that all handlers must/should/had better be a forwarding handler. I agree that it is certainly (one of) the most important use case, nevertheless, it is a restricting view of proxies which internal state has no reason to be reduced to a unique object. I would be more in favor of Proxy.ForwardingHandler, even if it's a bit long, I admit. > Extra inheritance chain step when resolving traps: > > Just a minor observation that, if proxy instance state is stored in > the own properties of a handler, and traps are inherited (as with > Proxy.Handler created handlers), then all traps are at least one step > up the inheritance chain. With shared handlers, traps would be on > average about one less step up the inheritance chain. I realize > prototype chain walking is highly optimized, but proxies allow for > transparent non-optimized user defined inheritance. The JS code in harmony:proxy_defaulthandler is given for illustration purposes. All of this will be native code, so there should be no performance issues. > Existing default handler useless to shared handlers: > ============================================================== > > The existing Proxy.Handler.prototype and all of its traps are useless > to a shared handler because they all have a reference to > "this.target". This could be resolved by replacing these references > with "this.getTarget(proxy)", but that again starts to pollute the > trap namespace. 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. This constraint would change the way forwarding proxies are created since the proxy object identity would need to be known before initializing the state. Hence we would probably need to do something like: https://gist.github.com/926581 We loose in simplicity (destructuring is helping though) but get all advantages mentionned above. The simplicity is lost because of the need of knowing the proxy object identity before being able to release the handler (order of lines 9-11 which cannot be changed). > Conversely, with a share-able Proxy.Handler, > handler-per-instance use cases could be accommodated simply by > wrapping a singleton pattern around a handler. I did not understand this point. Could you provide an example or a code snippet? David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
