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.
But the cost of allocating a WeakMap per object that wants private
properties, and then GC'ing it promptly per the guarantee, is the main
issue. When you need a WeakMap, this cost must be born. When you just
need private properties (pace Kevin on "need"), the allocation and the
GC mark/sweep overhead should not be imposed lightly.
Another issue, as mentioned: property access performance with private
symbols (or unique/public ones) will be much better, out of the gates.
Not a GC issue, just repeating so it doesn't get lost.
The major difference is how people will use each tool. From experience
in OO programming, most objects have a finite set of properties
determined at object creation time. It's true even in JavaScript where
objects are bags of properties. This allows to write "stable" code
(you can write "o.find()" assuming there is a find property which
value is an function). If people were creating eratic objects, writing
what I call "stable" code would be a much more complicated exercise.
This "cultural" use of objects is what makes optimizations like
Shape/HiddenClass possible.
Yup, I should have read ahead.
WeakMaps, on the other hand, are used as a maps key'ed on objects,
with the convenience that you don't need to clean the map when the
object is about to disappear. There is a assumption that when you
create a new weakmap, its use is largely independent of previous
weakmaps and it's unlikely 2 weakmaps will have the same set of
objects, so engines are unlikely to perform optimizations combining
different weakmap storages so that the values of the same key will be
close to one another or something like that.
WeakMap and Symbols each corresponding to a given patterns of use of
(object, object) -> value mappings. Although a unique feature could be
used to emulate the other, it would be very hard for an implementation
to optimize one feature for 2 patterns.
If anything, choosing one feature over the other is a way to tell your
coworkers and the JS engine which pattern you want to use.
Good point. There is inherent complexity in having two things, with some
overlap. I don't see it as fatal. I think Kevin's stronger point is
YAGNI re: high-integrity privacy, outside of SES use-cases.
But SES support is a goal of Harmony and ES6.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
