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

Andrea Giammarchi andrea.giammarchi at gmail.com
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 gmail.com>wrote:

> On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruant.d at gmail.com> 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] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
>> October/025962.html<https://mail.mozilla.org/pipermail/es-discuss/2012-October/025962.html>
>> [2] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
>> November/026114.html<https://mail.mozilla.org/pipermail/es-discuss/2012-November/026114.html>
>> [3] https://github.com/rwldrn/**tc39-notes<https://github.com/rwldrn/tc39-notes>
>> [4] https://github.com/rwldrn/**tc39-notes/blob/master/es6/**
>> 2012-11/nov-27.md#review-of-**new-draft-spec<https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md#review-of-new-draft-spec>
>> [5] http://wiki.ecmascript.org/**doku.php?id=harmony:**
>> specification_drafts<http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts>
>> [6] https://bugzilla.mozilla.org/**show_bug.cgi?id=814562<https://bugzilla.mozilla.org/show_bug.cgi?id=814562>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130121/a33f4af8/attachment.html>


More information about the es-discuss mailing list