direct_proxies "problem"

Brendan Eich brendan at
Thu Jan 10 22:41:40 PST 2013

Jason Orendorff wrote:
> On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>     Boris and I talked more 1:1 -- it is not clear when a direct proxy
>     can be safely "cast" to its target. The internal proxies Gecko
>     uses are known implementations where this is safe (with a security
>     check). An arbitrary scripted direct proxy? Not safe in general,
>     and stripping the proxy to its target may break the abstraction of
>     that certain scripted proxy.
> Hard-earned wisdom:
> 1. Proxies that form membranes always have wrap/unwrap operations that 
> can be sensibly applied in every situation—except access to an 
> object's implementation details, like internal properties; then it’s 
> unclear.
> 2. Proxies that exist only to give a particular object magical 
> behavior should never be "cast to its target".
> What 1 and 2 have in common is that only the handler ever sees both 
> the proxy and the target. The main lesson I've drawn from Mozilla's 
> experience with proxies is that this property is crucial.

I buy this analysis.

Still doesn't mean direct proxies are a net loss from the original 
target-free API. Direct proxies solved the non-configurable issue and 
simplified by eliminating function proxies as distinct at create-time. 
And one can use direct proxies as if they were indirect, with a dummy 
target and some work.

My old bones are aching in ways that make me think we could use two 
kinds of APIs. Notification proxies were suggested last fall. We have 
limited time for ES6 to call this, though.

> Without it, you get a mess that's impossible to reason about. The 
> symptoms are a proliferation of special cases where something must be 
> wrapped or unwrapped with a lengthy comment explaining why; code where 
> a particular variable could be either a target or a proxy; and related 
> bugs due to the code naively assuming one or the other.

Beyond the wrap/unwrap special casing, it sounds like proxied 
abstractions are leaking. Is this accurate and useful? Abstractions 
leak, utopia not an option....

> The default direct proxy you get with an empty handler does *not* have 
> this property; my hard-earned lesson predicts that we would therefore 
> have a lot of trouble figuring out exactly what that could usefully 
> do, and in fact we have had trouble. (It's not the only source of 
> trouble; access to object implementation details are trouble too.)
(Implementation details => abstraction leaks for sure, no?)


More information about the es-discuss mailing list