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.

/be

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