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 <bru...@enseirb-matmeca.fr> Date: Fri, Jan 21, 2011 at 3:08 AM Subject: On ES Harmony proxies extensibility To: es5-disc...@mozilla.org 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 es5-disc...@mozilla.org https://mail.mozilla.org/listinfo/es5-discuss -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
