On revoking access to the target of a proxy

David Bruant bruant.d at gmail.com
Fri Aug 3 16:27:43 PDT 2012


Le 03/08/2012 17:38, Sam Tobin-Hochstadt a écrit :
> On Fri, Aug 3, 2012 at 5:12 PM, David Bruant <bruant.d at gmail.com> wrote:
>> Le 03/08/2012 17:08, Sam Tobin-Hochstadt a écrit :
>>
>>> On Fri, Aug 3, 2012 at 5:03 PM, David Bruant <bruant.d at gmail.com> wrote:
>>>> With the current design, there is no way to cut the access to the target
>>>> and
>>>> enable its garbage collection because the target is an internal property
>>>> of
>>>> the proxy. It means that malicious or buggy code keeping a reference to
>>>> the
>>>> proxy keeps a reference to the target.
>>> Can't this be implemented using Tom & Mark's shadow target technique,
>> What do you call the shadow target technique? Can it be implemented with
>> direct proxies?
> Yes. See the discussion of `dummyTarget` in Tom and Mark's recent
> draft: http://soft.vub.ac.be/Publications/2012/vub-soft-tr-12-03.pdf
Quoting relevant section (tell me if I'm missing another relevant section):
"6.1. Virtual Objects
To create a virtual object using our Proxy API, it suffices to create a 
proxy with a dummy (perhaps empty) target object, and to have the 
handler ignore that target object. There are a couple of caveats though:
(1) The invariant enforcement mechanism discussed in Section 5.2 will 
not allow the handler to expose non-configurable properties or emulate a 
non-extensible object, unless the dummy object stores the exposed 
non-configurable properties or is itself non-extensible."

So your actual target can be GC'ed, but the dummyTarget has to keep 
observed non-configurable (and non-writable) properties. Or you can give 
up non-configurability.
I don't find any of these solutions satisfactory.

David


More information about the es-discuss mailing list