On Jan 21, 2011, at 11:10 AM, Andreas Gal wrote: > 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.
Meta-level shifting (AKA double lifting) wants no stray "object detection" gets, or you'll create traps in the meta-handler where you shouldn't (e.g., the spec-internal IsCallable helper). See http://wiki.ecmascript.org/doku.php?id=strawman:uniform_proxies#iscallable > We have previously discussed adding standard handlers to the specification, > i.e. an NoopHandler and a ForwardingHandler. The latter is proposed: http://wiki.ecmascript.org/doku.php?id=strawman:proxy_defaulthandler > 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). Should we have a no-op or "sink" standard handler too? /be > > 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 <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 > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
