Hi David, What does exactly "not be trapped" mean? If you define a property on a proxy object, the defineProperty trap of the handler is the only method with which that operation can succeed. If defineProperty doesn't exist you want us to just ignore the operation?
I think this approach has some pretty several problems. If a programmer writes down 6 of the 7 mandatory traps and forgets one, it will be very hard to debug why the proxy doesn't work as expected. Corresponding operations just disappearing in a black hole is not very intuitive. I am not completely dismissing your concerns. We are using proxies internally in Firefox and most people I have seen use them for the first time make exactly the mistake your code does below: not implement all the mandatory traps. The resulting error messages are not very intuitive, but they are a reflection of the language semantics behind the scene. For some specific reasons Mark can explain better than me the spec doesn't want the implementation to verify the existence of all 7 mandatory traps, so thats not really an option either. We have previously discussed adding standard handlers to the specification, i.e. an NoopHandler and a ForwardingHandler. You can delegate to these from your handler to get the desired default behavior. I think this is the best of the someone poor choices we have. It catches accidental trap omissions, but still allows you to leave them out as long you pick a default behavior (and it doesn't force a specific default behavior down people's throat). Andreas On Jan 21, 2011, at 8:43 AM, Mark S. Miller wrote: > Hi David, I'm forwarding your message to es-discuss as it has no direct > relevance to ES5 per se. > > All, please reply only on es-discuss. > > ---------- Forwarded message ---------- > From: David Bruant <[email protected]> > Date: Fri, Jan 21, 2011 at 3:08 AM > Subject: On ES Harmony proxies extensibility > To: [email protected] > > > Hi, > > Working on writing the MDN doc for ES Harmony proxies > (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy), > I've studied the proxies and would like to provide some feedback. > > My main concern in the proposal (and its current implementation on FF4b9) is > the following sentence: "handler is an object that at minimum implements the > following API" (7 functions). At first, I didn't understand why and then I > have tried the following : > -------- > var p = Proxy.create({get: function(proxy, name) { > return 'Hello '+ name; > } > }); > > Object.defineProperty(p, 'a',{value:1}); > -------- > In FF4b9, this code triggers an error : "defineProperty is not a function". I > interpret this as: the proxy traps the defineProperty call, then calls > handler.defineProperty which is undefined. > It gets a bit more weird when a derived trap is called. If undefined in the > handler, the default behavior is called. This behavior uses one of the > fundamental trap (by definition of "derived trap"). If this fundamental trap > isn't implemented in the handler, an error is thrown about the fundamental > trap which is not very intuitive. This is more of an implementation concern, > but it could be given as an advice for future implementation. > > Since proxies "trap" all traps (fundamental and derived), all fundamental > traps need a handler method. I think that it can be the cause of a problem > for the Proxy standard extensibility: > Let's assume that, at some point, the Proxy proposal gets standardized. It > will have a well-defined set of fundamental traps and of derived traps. > People are going to write applications with them.They are going to implement > the 7 fundamental traps. This is code in the wild. > > Let's assume (and this assumption is the one to discuss, I think) that the > TC-39 comittee wishes to extend the number of fundamental traps with a > fundamental trap 'FT'. This wish won't be able to be fulfilled, because > proxies will be already implemented and used. These proxies handler will > implement the 7 fundamental traps (not the 8th one) and consequently executed > on an ES engine with support of the 8th trap, it will trigger some sort of > error ("FT is not a function") each time the behavior trapped by FT happens. > Potentially breaking existing code, adding FT will be impossible. > > My point is that as soon as Proxies will be standardized, it will become > impossible to add fundamental traps without either breaking existing code or > becoming inconsistent. > > > In my opinion, the extensibility problem is due to the fact that all traps > are trapped by default in proxies regardless if the user wants it or not. > Please allow me an analogy with DOM events. I see proxy traps as "events on > ECMAScript objects". When in the code a "delete" happens, a /delete/ event > happens, it is trapped and the delete handler function is called like a event > handler for a DOMEventListener. > Capturing all events by default and forcing "proxy authors" to implement all > event handlers would be the equivalent to say to web authors "implement > handlers for all DOM events for all DOM node". The scale is different, so it > sounds really ridiculous this way, but the result is the same with the > current proxy default behavior. And as this behavior prevent Proxy extension, > it would prevent addition of new DOMEvent if this had been the chosen model > at the time. > Another problem I see from the proxy author point of view is that proxies as > they are allow some non-intuitive code writing. When I started to write the > handler with just a 'get' method, I expected the proxy to only "capture", > "trap" only "get code" (proxy.property) like a lot of examples (in proxy > presentation slides > (http://www.slideshare.net/BrendanEich/metaprog-5303821) or in Tom Van Cutsem > tutorial (http://soft.vub.ac.be/~tvcutsem/proxies/)) seemed to imply (that's > at least how I was interpreting them). > A potential last problem that goes with trapping everything by default is > performance. If we had the potential to only trap "events" we've registered > for (by explicitely providing a function), other "events" wouldn't be trapped > and thus, there could be no need to check if there is a function, etc. > > In my opinion, the solution to solve the extensibility problem, the > non-intuitive code problem and the potential performance problem would be to > only trap events that have explicitely a function for it. If there is no > function, instead of providing a default behavior, the event could just not > be trapped. > > I am new on this mailing-list. I hope it was the right place to provide this > feedback. > > Thanks for reading, > > David > > _______________________________________________ > es5-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es5-discuss > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
