Private Slots

Brendan Eich brendan at mozilla.com
Tue Jan 15 14:27:12 PST 2013


Mark S. Miller wrote:
> On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> David Bruant wrote:
>>> In theory, private symbols should have the same GC issues than WeakMap.
>>> Consider:
>>>
>>>      var o = {}, o2 = {};
>>>      for(var i=0, i<1000, i++){
>>>          let s = new Symbol(true /*private*/);
>>>          o[s] = o2[s] = i;
>>>      }
>>>
>>> Here, private symbols are created, properties are added. Because of
>>> let-locality, every symbol can be GC'ed, because at the end of the loop, no
>>> one can ever access any of the symbols. The equivalent of the WeakMap GC
>>> property would want properties in o and o2 to be removed too. I'm willing to
>>> bet this will never happen in any JS engine.
>> This is not the "GC issue" that was raised, precisely because WeakMap does
>> make no-cyclic-leak guarantees that Symbols as used in your example do not.
>>
>> So Symbols could have the leak problem that WeakMaps cure, and that is
>> another issue.

This stuff still stands.

>> But the cost of allocating a WeakMap per object that wants private
>> properties,
>
> I'm not following this. Why would you allocate more WeakMaps than you
> would have allocated private symbols? If the goal is per-class
> privacy, which is the private symbol use case, you'd allocate one
> WeakMap per field per class just as you would have with private
> symbols.

The savings comes from prototypal inheritance. Given one class with 2 
private methods, you need only 2 symbols. These are flat frozen objects, 
maybe even internally more efficiently represented.

Given one class with 2 private weakmaps, you need those two weakmaps, 
indeed also allocations -- but then they must expand to index every 
instance of the class!

/be


More information about the es-discuss mailing list