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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
