On revoking access to the target of a proxy

David Bruant bruant.d at gmail.com
Sat Aug 11 07:46:43 PDT 2012


It's been a couple of days that this thread has had no update and 
specifically no answer to Mark Miller's question "Other than the 
additional complexity, which is a significant argument against, what 
other arguments are there against enabling a proxy to drop its target?"
So I guess we can assume agreement (until proven otherwise) on the 
necessity of a language construct for revoking target access and can 
consider moving forward on the "how".

Here are 3 proposals I made:
> * A Proxy.revokeTarget(proxy) & corresponding revokeTarget trap 
> (returns a boolean to decide whether to procede or not). After the 
> access to the target has been revoked, any attempt to touch the proxy 
> throws an exception without trapping (very much like transferable 
> objects when they've been transfered IIRC).
> If no revokeTarget trap is provided, the target is not revoked (return 
> false by default).
> Called on a non-proxy object, Proxy.revokeTarget does nothing.
> Of course, if someone else holds a reference to the target, it is not 
> garbage-collected no matter how many proxies have been revoked access 
> to it.
> * Alternatively, the proxy constructor returns a pair so that only the 
> proxy creator has access to the revoke method (removes the need for 
> the trap). But it induces boilerplate when you don't care about 
> revokability.
> * Alternatively, having 2 constructors, Proxy and RevokableProxy. The 
> former is the one for current direct proxies, the latter returns a 
> pair as described in the second proposal.

I tend to favor the third proposal because revokability is not 
everyone's use case and having "new Proxy()" returning a proxy seems 
more intuitive.

Are there other proposals? other preferences?


More information about the es-discuss mailing list