On Nov 26, 2014, at 11:25 AM, Tab Atkins Jr. wrote: > On Wed, Nov 26, 2014 at 11:23 AM, Mark S. Miller <erig...@google.com> wrote: >> On Wed, Nov 26, 2014 at 11:09 AM, Allen Wirfs-Brock >> <al...@wirfs-brock.com> wrote: >>> >>> On Nov 26, 2014, at 10:22 AM, Claude Pache wrote: >>> >>> >>> The root of the issue, is that WeakMaps are thought as a tool for two >>> unrelated use cases. Quoting [1]: >>> >>> (...) WeakMaps were motivate[d] by two distinct use cases. Soft fields and >>> object-keyed caches. >>> >>> >>> Now, in short, for the "soft fields" use case, a `.clear()` method is >>> unwanted, but for the "object-keyed caches" use case, a `.clear()` method is >>> welcome. >>> >>> —Claude >>> >>> [1]: https://esdiscuss.org/topic/weakmap-clear-and-inverted-implementations >>> >>> >>> Let's ignore security for the moment. >>> >>> If WeakMaps/WeakSets are not inspectable (via iteration) and do not have a >>> clear operation, then the inverted implementation technique can be use used. >>> This technique eliminates significant GS complexity. >>> >>> The ability to iterate over the elements of a WeakMap/Set would make >>> implementation specific (and probably non-deterministic) GC timing >>> observable to ES programs. Non-deterministic and observable implementation >>> specific behavior is bad for interoperability. >> >> Hi Allen, as much as I'd like to agree with this, I don't see the >> observability-of-GC issue. Could you explain more? Thanks. > > Allen appears to be mixing in an iterability argument. This isn't > germane to the .clear() discussion, unless you think of .clear() as > being implemented by iterating and removing keys.
Right, it's the lack of iterability and clear that makes the inverted implementation feasible. We justify lack of iterability because it exposes GC. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
