On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich <bren...@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.
>
> 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.
> 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
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
