Removal of WeakMap/WeakSet clear

[Allen Wirfs-Brock]

On Nov 26, 2014, at 11:25 AM, Tab Atkins Jr. wrote:

> On Wed, Nov 26, 2014 at 11:23 AM, Mark S. Miller <erights at google.com> wrote:
>> On Wed, Nov 26, 2014 at 11:09 AM, Allen Wirfs-Brock
>> <allen at 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