Mark S. Miller wrote:
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich<[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
