On revoking access to the target of a proxy

Brendan Eich brendan at mozilla.org
Sat Aug 11 13:29:20 PDT 2012

You made a good point, one I thought we had touched on at the last TC39 
meeting, but apparently not.

Tom is on vacation till 17 August, so expect to hear back from him after.


David Bruant wrote:
> Hi,
> 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?
> 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