David Bruant wrote:
Le 18/04/2012 19:48, Brendan Eich a écrit :
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
I agree with your point.
However, I'd like to restate that interaction between proxies and
private names as currently design is unusable:
var callName = import @call;
var target = {
[callName]: function(){console.log('yo')}
};
Just as an aside, and to avoid confusion (import doesn't work that way),
let's say it is:
var target = {
@call: function(){console.log('yo')}
};
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.
Tom, didn't our thinking on private names predate direct proxies? Or is
that not relevant? In the old model, the handler would need traps (some
fundamental ones at least) that special-case the public name substituted
for @call. Perhaps we need something more automagic for direct proxies
that still prevents private name leaks.
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?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
