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

Mark S. Miller erights at google.com
Mon Jan 21 10:43:57 PST 2013


On Mon, Jan 21, 2013 at 9:38 AM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> somebody asked why clear() is needed, when if you have the reference you can
> simply ref = new WeakMap;

Thanks for pointing this out. The clear method in my wrapper should have been

    clear() { wrapped = 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
>>> [2]
>>> https://mail.mozilla.org/pipermail/es-discuss/2012-November/026114.html
>>> [3] 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
>>> [5] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
>>> [6] 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
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list