Questioning WeakMap.prototype.clear (was: Private symbols as WeakMap sugar)

Andrea Giammarchi andrea.giammarchi at
Mon Jan 21 09:38:42 PST 2013

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().

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.

Thanks and have a nice day or evening

On Mon, Jan 21, 2013 at 8:16 AM, Rick Waldron <waldron.rick at>wrote:

> On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <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]**pipermail/es-discuss/2012-**
>> October/025962.html<>
>> [2]**pipermail/es-discuss/2012-**
>> November/026114.html<>
>> [3]**tc39-notes<>
>> [4]**tc39-notes/blob/master/es6/**
>> 2012-11/**new-draft-spec<>
>> [5]**doku.php?id=harmony:**
>> specification_drafts<>
>> [6]**show_bug.cgi?id=814562<>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list