Membranes, unmediated access to objects through Object.getPrototypeOf

Brendan Eich brendan at mozilla.org
Wed Oct 10 15:53:47 PDT 2012


David Bruant wrote:
> 2012/10/10 Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>>
>
>     Tom Van Cutsem wrote:
>
>         We should also be wary of adding even more Proxy constructors,
>         as we'll otherwise end up with a combinatorial explosion
>         (revocable branded proxies, branded proxies with a symbol
>         whitelist, etc.)
>
>
>     But didn't David find a way to avoid Proxy.revocable, namely make
>     revocation swap in an all-throwing-traps handler?
>
> Unfortunately no. I agree with Tom concern of combinatorial explosion, 
> because we will have revocable, branded, and what's next?
> However, the symbol whitelist isn't part of it. The whitelist doesn't 
> make a new type of proxies.

Yes, I agree with all that (except the revocable constructor, see 
below), including general apprehension of combinatorial explosion.

>     Just trying to keep up here (and hoping we indeed avoided a
>     revocable proxy constructor).
>
> Even with the idea of native support for membrane as I presented it, 
> it doesn't change that anyone holding a reference to a proxy 
> indirectly keeps a reference to the target, thus causing the GC to not 
> be able to collect the target.

Why would not the target be nulled and the handler be replaced with a 
handler full of throwing traps? Sorry if I missed a message on this.

> We need platform support for revocation, because it cannot be 
> implemented by JS code.

I quite agree, but this does not mean a Proxy.revocable constructor, 
unless you want a revoke method to work only on proxies distinguished by 
being created via an alternative constructor.

IIRC (and I hope I do!) we were considering RevokableProxy or 
Proxy.revocable only because non-revocable proxies cannot tolerate 
overhead in dispatching their traps to check for a default-false revoked 
internal property. But your idea of nulling target and replacing handler 
with a throwing handler seemed to avoid any overhead.

So is the issue the revoke API and a desire to "narrow" it to apply only 
to proxies distinguished from birth as revocable? If so, why?

/be

> All in all, membranes can be implemented today. I find the idea of 
> using dummy targets a bit awkward, but it works. If after some 
> experience using proxies, the cost turns out to be prohibited, There 
> is still room for improving proxies with what proposed or whatever 
> else in a later version of the spec I think. The issue I'm pointing is 
> not as urgent as the revocation issue was.
>
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list