Le 19/04/2012 01:00, Brendan Eich a écrit :
David Bruant wrote:
var p = Proxy(target, {});
p(); // throws exception because the proxy is reported as not
having
// a @call property
In the get trap of the proxy, the @call private name is transformed into
its public conterpart. When, by default, the trap forwards to the
target, the public alter-ego is coerced into a string. Consequently, the
actual @call property of the target isn't found.
Hmm, I see. The idea was to avoid leaking private names via hostile
proxies, but here we have a friendly proxy that wants to get the
private-named target property.
Yes. The interaction of proxies and private name has only been
considered under the consideration that proxies can be hostile. And
indeed, there are cases where there is no need to protect the private
name from the proxy. One is publicly available private names (aka
"unique names").
That was the root of the reasoning behind "Alternative proposal to
privateName.public" [1].
I've summurized some approaches [2] that could be taken.
With direct proxies, if the target already has the private-named
property, and the handler ({} here) has no traps that might steal a
non-substituted private name, why would we substitute the public name
for the private @call?
This doesn't scale. Private names could be added or removed from the
target by some who have direct access to it (not intermediated with a
proxy).
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-December/018908.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-December/019005.html
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
