On revoking access to the target of a proxy

David Bruant bruant.d at gmail.com
Wed Aug 22 08:28:28 PDT 2012


Le 21/08/2012 17:41, Tom Van Cutsem a écrit :
> (sorry for the slow reply, catching up on e-mail)
>
> So the old fix() trap is back with a vengeance, it seems!
It's a very different form, but I see the analogy.

> To answer Mark's question of what other downsides there are to 
> dropping the target:
> 1) it would require an additional check on every trapped operation to 
> verify whether the proxy is revoked or not, throwing an exception if 
> it is. Nothing critical since we're already on the slow path, but this 
> "revocation" check is new overhead.
For the sake of the spec maybe, but in-memory, at revokation time, the 
proxy object can be swapped with an "unconditonnally-throw-when-touched" 
object. In that situation, there is no need for a "revocated" boolean 
and related check on pre-trap.

> 2) it reintroduces a subtle issue from the old design that had to do 
> with fixing a proxy while it still has pending trap activations on the 
> runtime stack: an unrevoked proxy may call one of its traps and be 
> revoked by the time the trap returns.
As a complement to what you're saying, in this case, the proxy user 
revokes the proxy (intentionally or not) in the middle of a normal 
object operation (get/set/has/etc.). After this operation, the proxy is 
revoked. We can say "revoked internally" since it has not been does by 
an external proxy user, but a trap.

> For invariant enforcement to work correctly, the trap's result must be 
> verified against the original target.
Or should it just throw, considering that no invariant holds for 
internally revoked proxy?
Returning a last result while the proxy has been internally revoked 
might be considered as a leak.

     var revoke;
     var handler = {
         get: function(){
             revoke();
             return 1;
         }
     }

     var {revoke, p: proxy} = new RevokableProxy({}, handler);

     var a = p.prop; // should "a" be 1 or should this operation throw 
on post-get trap?
     var b = 'yo' in p; // throws anyhow without even calling the has 
trap because p has been revoked

While I said above that a before-trap check can be removed, I think a 
post-trap check is necessary for this idea.

I have no strong opinion as for what is best between doing a "last 
successful operation" or throwing for internally revoked proxies, I just 
wanted to share this option for the sake of completeness.

David


More information about the es-discuss mailing list