callable objects ?

David Bruant bruant.d at
Thu Apr 19 01:03:01 PDT 2012

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 



More information about the es-discuss mailing list