[Proxies] VirtualHandler fundamental traps: defaults

Tom Van Cutsem tomvc.be at gmail.com
Mon Dec 12 07:40:51 PST 2011


While working on the specification of the VirtualHandler <
http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api> for
direct proxies, I came across the following:

As can be seen on that page, I originally considered specifying the
fundamental traps of the VirtualHandler to be "abstract": the intent is for
them to be overridden by client code (think Smalltalk "self
subclassResponsibility"-style methods).

However, as noted on the bottom of that page <
an alternative would be to simply provide default implementations for
fundamental traps as well. The defaults given there are, I think, the only
reasonable defaults in the absence of further information.

I think this set of alternative defaults is actually more useful than
requiring the fundamental traps to be abstract. For example, consider the
Higher-order message proxy object (defined on the old Proxy API page: <

With direct proxies, one could reimplement that object as follows:

var dummyTarget = {};
var _ = Proxy(dummyTarget, { get: function() {...} }); // note: handler
only implements "get", default traps for all the rest

This works, as long as client code only ever uses property access on "_".
Property addition, deletion etc. will all affect the dummyTarget instead,
which is not really what was intended:

_.x = 1; // default behavior, equivalent to dummyTarget.x = 1
_.x // triggers get trap, doesn't return 1

Better would be to use the VirtualHandler to implement "_" as follows:

var handler = Object.create(VirtualHandler.prototype);
handler.get = function() { ... }; // override only "get", inherit default
traps from VirtualHandler
var _ = Proxy(dummyTarget, handler);

Since VirtualHandler implements the full handler API, property addition,
deletion, enumeration etc. will no longer be forwarded to the dummyTarget.
If we choose reasonable defaults for fundamental traps as well, the above
code is sufficient. The "_" object now behaves more reasonably in that you
cannot add properties to or remove properties from it.

If, on the other hand, we choose fundamental traps to be abstract, the
above code is "incomplete" and we should additionally override all
fundamental traps to do something sensible (in this case, I would argue
that the sensible thing to do is to implement exactly the default semantics
from the "open issues" section).

So in short I would prefer sensible defaults over error-throwing missing
fundamental traps.
I'd be interested in hearing others' thoughts about this.

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

More information about the es-discuss mailing list