Hi Tom,
Thanks for this summary.
About the first proposal and getting rid of the whitelist, indeed, the
whitelist was here to tell about known symbols to avoid leakage. If
private symbols pierce proxies, the whitelist has no purpose any longer.
I don't understand why problem B isn't solved with the first proposal.
Since the proxy is pierced, access to private symbol'ed properties don't
trap and the proxy can't throw on access (since it's not trapped).
If I'm misunderstanding the proposal, could you show an example, under
the unconditional forwarding proposal in which the problem B can be
reproduced.
The second proposal reminds me a bit of an evolution of the first proxy
design in which each proxy would have its own storage for invariant
checks. Since a forwarding proxy was the main use case and already had a
storage area (the target), this led to the second design "direct proxy"
in which both storages would be merged in the target.
By analogy, the natural evolution of the second proposal would be the
first proposal.
David
Le 28/01/2013 19:45, Tom Van Cutsem a écrit :
I just wrote up a strawman on the wiki to summarize the recent debates
about the interaction between proxies and private symbols:
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled
The page actually lists two proposals, out of which I prefer the
second one.
If I forgot some benefits/drawbacks of either approach, please speak
up. Thanks.
Cheers,
Tom
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
