2012/8/22 David Bruant <bruan...@gmail.com> > Le 21/08/2012 17:41, Tom Van Cutsem a écrit : > >> 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.
Not necessarily: the trap, while executing, may call on some external code which then does the revocation, so there's no reason to call it "revoked internally" (i.e. the revocation may happen arbitrarily deep in the call stack, it may not occur lexically in the scope of the 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. > > [example snipped] > > 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. The way proxies are currently specced (see < http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec#proxy_internal_methods>), the [[Target]] of a proxy is always read into a local variable before calling the trap, and in the post-trap assertion checks, this local variable is then used. Thus, it doesn't matter whether the proxy was revoked in the mean time or not. I don't see the harm in still allowing pending trap activations to return gracefully upon revocation. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
