WeakMap better than Private Symbols? (was: direct_proxies "problem")

Brendan Eich brendan at mozilla.com
Thu Jan 10 09:19:38 PST 2013

Nathan Wall wrote:
> Brendan Eich wrote:
>> Nathan Wall wrote:
>>> In the case of (2), the implementation using a private symbol will fail on a call to `setTime` when the object is frozen (I think).
>> Nope, we agreed that frozen objects support setting pre-existing (added
>> before the object was made non-extensible) properties named by private
>> symbols.
> I wasn't aware, but that significantly improves the case for symbols. I'm glad to hear it!  However, it also begs the question of why symbols should behave differently from WeakMaps/closures in the presence of Proxies (via unknownPrivateSymbol trap).

WeakMaps transpose the terms of property access:

  obj[sym] <=>  wm[obj]

This seems important! Do you propose, if obj is a proxy, to trap with wm 
as key for the latter?

> David Bruant wrote:
>>> In the case of (1), the implementation using a private symbol will have internal accesses to the `timestamp` symbol exposed through the unknownPrivateSymbol trap.
>> The trap does not expose the symbol. That would be a bad leak.
>> The third "whitelist" argument in the proxy constructor is here to
>> communicate whether the proxy knows the privatesymbol or not.
>> When [[Get]] or [[Set]] (or other property operations) happens with a
>> whitelisted private symbol, the get or set (or other) trap is called
>> with the symbol itself (since it's known). If the name isn't in the
>> whitelist, the unknownPrivateSymbol trap is called with target as the
>> *only* trap argument (the private name is not exposed and that's on
>> purpose!)
> I'm sorry, I was unclear. I understand that the symbol itself is not exposed, but the fact that some symbol was accessed is.

No, not if the symbol is not in the whitelist. Zero information leak is 


More information about the es-discuss mailing list