Removal of WeakMap/WeakSet clear

[Claude Pache]

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


> Le 26 nov. 2014 à 18:33, Katelyn Gadd <kg at luminance.org> a écrit :
> 
> Is there a detailed rationale for this somewhere? Making typical
> applications pay the cost here for a specific security scenario seems
> really bizarre to me. Clearing standard library data structures is an
> incredibly common operation. If you want to ensure that someone can't
> clear the map/set, shouldn't you be handing them an encapsulated
> version of the data structure? This seems like a corner case that
> shouldn't justify removing an important primitive.
> 
> If you have a clear method, the security problem seems solved by
> wrapping it in an object or using a proxy to deny the ability to clear
> (you hide the actual map/set, so it can't be cleared - you expose only
> the operations you want to expose).
> 
> If you don't have a clear method, anyone wanting to clear the data
> structure has to throw it away and allocate a new one. This has
> significant disadvantages:
> The new structure starts empty at a default size, so repopulating it
> will have to grow the buffer multiple times - this is undesirable for
> cases where you are reusing a single data structure to store state for
> a long-running application.
> The allocation adds to GC and memory pressure for a long-running
> application that needs to clear data structures frequently. Were it a
> lightweight data type this would matter less, but a typical map
> instance with data in it can occupy a considerable amount of space in
> the heap.
> Being able to clear the structure now requires that all consumers have
> support for replacing their reference(s) to the old map with the new
> one. This makes it harder to maintain encapsulation because you may
> have saved a reference to the map in a private property or within a
> closure. Now you need to add accessibility points to everything that
> might retain the map so that you can update the reference. Or, you
> have to encapsulate maps and sets just to recreate the clear operation
> that should have been there to begin with.
> 
> In either case, encapsulation or shielding the container behind a
> proxy is necessary. I insist that the common case is the one that
> shouldn't have to encapsulate, because optimizing for that case will
> benefit the vast majority of web applications that use it and the
> penalty to security-sensitive cases is small.
> 
> -kg
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss