Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

Tom Van Cutsem at
Wed Nov 14 12:12:46 PST 2012

2012/11/14 Allen Wirfs-Brock <allen at>

> On Nov 14, 2012, at 1:25 AM, Tom Van Cutsem wrote:
> - You don't need to subclass Handler if you are building proxy
> abstractions that only do before/after/around-style wrapping of a target
> object. Even if you implement only some of the traps and leave the others
> in "forwarding mode", as even your own traps eventually "forward", the
> resulting proxy is still consistent.
> Yes, a very good point and one that isn't necessary obvious in the present
> APIs and documentation.

I guess that depends on how you look at it.

Granted, the current documentation is lacking in this respect. Of course,
most Proxy docs were written with specification in mind, and were not
written from the point of view of how to use the API effectively.

On the other hand, there are many aspects of the direct proxies API that
clearly signal the wrapping use case: the fact that traps default to
forwarding, the fact that all traps receive the wrapped "target" object as
first argument, the fact that the Reflect object makes it particularly easy
to forward intercepted operations, etc.

I always like to categorize proxy abstractions in two groups:
1) proxies that wrap other objects (revokable references, membranes,
tracers, contacts, ...)
2) proxies that don't wrap other objects directly ("virtual" objects) (e.g.
test mock ups, unresolved promises, remote objects, ...)

The old proxy API clearly favored use case (2) over (1). One can view the
entire shift from old proxies to direct proxies as a way to better support
(1) over (2). And this shows: the footgun that was raised in this thread
essentially derives from the difficulty of building virtual objects with
direct proxies, which favor forwarding. With the old API, things were
exactly the other way around.

With the old API, we had the "ForwardingHandler" to more easily support use
case (1).
With the direct proxies API, we have the "Handler" (previously called
"VirtualHandler") to more easily support use case (2).

I think that's striking because both the ForwardingHandler and
VirtualHandler APIs really grew organically from their respective Proxy
APIs. When Mark and I started designing direct proxies, it wasn't clear to
us (at least not to me) at that time that we needed to replace the old
ForwardingHandler (a handler that facilitates forwarding) with its exact
dual (a handler that prevents forwarding).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list