On Tue, Jan 15, 2013 at 12:10 PM, Tom Van Cutsem <tomvc...@gmail.com> wrote: > In defense of Kevin, I too would argue that private symbols add complexity > to the object model. > That doesn't mean I'm arguing in favor of removing private symbols, just > noting that we do pay a complexity price. > > We should not deny that with the addition of private symbols, we had to > reconsider every existing ES5 operation to see whether it needed to be > adjusted so that it does not leak private symbols. We happen to be lucky > that Object.keys and Object.freeze can be thought of as using > Object.getOwnPropertyNames, so adjusting gOPN (and the Proxy API) closed all > leaks identified thus far. Going forward from here, we need to continue to > be vigilant about private symbol leaks. > > I also think Kevin is making the fair point that for the 99% use case, > unique symbols are sufficient. For software engineering purposes, they > provide good enough encapsulation. "private" in Java is not really private > due to java.lang.reflect, but that doesn't stop people using it to express > encapsulation. > > Since Kevin is merely asking for a good explanation of why private symbols > are "in", I would say that it's because TC39 explicitly wanted symbols to be > usable for high-integrity encapsulation scenarios. > > Kevin's reply to that is "if the use case is high-integrity encapsulation, > why aren't WeakMaps sufficient?" > > The response to that is: WeakMaps add more boilerplate and more overhead. I > don't think the WeakMap boilerplate overhead is an actual issue for people > writing defensive code (such code already has to go so out-of-its-way, e.g. > by using early-bound primordials, I think it can deal with WeakMaps). The > performance argument still stands though.
*If* the only thing keeping private symbols alive is this performance argument, then I think they could die. The performance issue with WeakMaps is easily fixed with a boolean hint that I suggested a long time ago. It was dropped as too complex, which I appreciate, but if it enables dropping something yet more complicated.... Independent of this hint, wm.set(key, value) needs to make value reachable if wm *and* key are reachable. In the absence of this hint, to assess the space complexity of an algorithm expressed using WeakMaps, we may assume that the value is not made reachable any longer than that[1]. With the hint, we may only assume that the value does not outlive the key. It may very well outlive the WeakMap. This allows an implementation to use exactly the same implementation techniques internally for these wimply weak maps that we expect them to use for private symbols. [1] if not otherwise reachable of course On Tue, Jan 15, 2013 at 12:30 PM, David Bruant <bruan...@gmail.com> wrote: [...] > I agree there is an equivalent between private symbols and weakmap. Both are > a (object, object) -> value mapping (symbols can be getters, etc, but it > could be implemented with weakmaps too) > > In theory, private symbols should have the same GC issues than WeakMap. [...] > 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. Without a hint. > 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. Or the hint could be. Although the hint and the expectations it signals is complex, it has no semantics beyond this difference in ability of a program to claim asymptotic space complexity. And really, these claims are a lie anyway <http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics>, since we've never made it normative that a JS engine must collect any garbage at all, much less which garbage. Nevertheless, I am not advocating that we drop private symbols, at least at this time. My point is only that the performance issue, by itself, is not a reason to keep them. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
