Fwd: On ES Harmony proxies extensibility

Mark S. Miller erights at google.com
Fri Jan 21 08:43:23 PST 2011

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 <bruant at enseirb-matmeca.fr>
Date: Fri, Jan 21, 2011 at 3:08 AM
Subject: On ES Harmony proxies extensibility
To: es5-discuss at mozilla.org


Working on writing the MDN doc for ES Harmony proxies (
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
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,

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

Thanks for reading,


es5-discuss mailing list
es5-discuss at mozilla.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110121/370021a1/attachment.html>

More information about the es-discuss mailing list