Hi, 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 < http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api#open_issues>, 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: < http://wiki.ecmascript.org/doku.php?id=harmony:proxies#higher-order_messages >): 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. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
