Questioning WeakMap.prototype.clear

David Bruant bruant.d at
Mon Jan 21 09:48:33 PST 2013

Le 21/01/2013 18:38, Andrea Giammarchi a écrit :
> somebody asked why clear() is needed, when if you have the reference 
> you can simply ref = new WeakMap; instead of clearing, while clear() 
> exposes undesired side effects.

> Said that, even localStorage lets us remove all keys even if it wasn't 
> us setting them so ... well, I guess we can survive then with clear().
are you using localStorage as a model of high integrity API? ;-)
Regardless, the problem is different. localStorage methods deal with a 
persistent remote resource. An empty localStorage without .clear would 
require a lot of back and forth exchanges between disk and JS.
If you want an empty weakmap, you can just create a new one and get rid 
of the previous one. GC will do the cleanup at a time it finds relevant; 
maybe even in parallel of your program one day?

> This is specially for Rick, since it's holidays today and I am bored 
> home :D
> Where is exactly the latest state of es6 collections? I have no idea 
> how I should update mine accordingly, please point me to the very 
> latest, most updated, agreed link 'cause I am confused.
Latest draft at


> Thanks and have a nice day or evening
> On Mon, Jan 21, 2013 at 8:16 AM, Rick Waldron <waldron.rick at 
> <mailto:waldron.rick at>> wrote:
>     On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruant.d at
>     <mailto:bruant.d at>> wrote:
>         I think WeakMap.prototype.clear slipped through the crack
>         without being specifically discussed. Based on what's publicly
>         available, I don't see anyone noticed and discussed the fact
>         that WeakMap.prototype.clear questions the property that was
>         true before its adoption ("you can only modify a weakmap entry
>         if you have the key")
>     I agree and disagree. I disagree because WeakMap.prototype.clear()
>     doesn't modify the weakmap entry in the same direct way, ie.
>     WeakMap.prototype.set, WeakMap.prototype.delete. On the other
>     hand, I agree because it provides (if the weakmap is exposed) a
>     way to remove an entry that might be used without any defense, ie.
>     WeakMap.prototype.has() or might leave the program in an unstable
>     state due to loss of some aggregate state information stored in
>     the weakmap.
>     That being said, I support the inclusion of
>     WeakMap.prototype.clear(), because reasonable security and state
>     defense expectations can be met by:
>     1. Not exposing a sensitive weakmap in program code
>     2. Defending against missing entries with has()
>     Subjectively, #1 mitigates without nannying.
>     Rick
>         I think the property I mentioned is cricial to weakmap
>         integrity and I think WeakMap.prototype.clear should be
>         considered for removal... or at least proper discussion since
>         none really happened from what I've found.
>         David
>         [1]
>         [2]
>         [3]
>         [4]
>         [5]
>         [6]
>         _______________________________________________
>         es-discuss mailing list
>         es-discuss at <mailto:es-discuss at>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list