Membranes, unmediated access to objects through Object.getPrototypeOf
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?
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss