callable objects ?

Brendan Eich brendan at mozilla.org
Wed Apr 18 16:00:33 PDT 2012


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


More information about the es-discuss mailing list