On revoking access to the target of a proxy

David Bruant bruant.d at gmail.com
Sat Aug 4 15:37:47 PDT 2012

Le 04/08/2012 16:32, Mark Miller a écrit :
> On Aug 3, 2012, at 5:58 PM, David Bruant <bruant.d at gmail.com> wrote:
> [...]
>> In the end, revokability can be implemented, but the nice GC property that should come along can only be implemented if the revokable proxy does not support invariant checking. Regardless, it still requires to delete all configurable properties of the dummy target on revokation, which may take some time.
>> As we've seen with the Hueyfix, having enabling GC thanks to revokation sometimes yields tremendously excellent results (whether the properties of the GC'ed objects are configurable or not, this should not matter). I think it justifies language-level revokability.
> I see you point. This gc issue surprises me.
It really was a non-obvious loss in the switch from the previous design 
to direct proxies.

> I agree it seems serious. I hate to complexify the proxy design yet further, but I don't see how a library could workaround this restiction otherwise.Other than the additional complexity, which is a significant argument against, what other arguments are there against enabling a proxy to drop its target?
I only have an additional argument in favor. Transferables (and private 
names?) will require the implementation of objects which will throw when 
touched. Also, Hueyfix included DeadObjectProxies [1].
So it seems JS impls that the implementation cost of this feature is 
mostly already paid.


[1] https://hg.mozilla.org/mozilla-central/rev/cc5254f9825f#l7.13

More information about the es-discuss mailing list