Questioning WeakMap.prototype.clear

Rick Waldron waldron.rick at gmail.com
Mon Jan 21 11:36:49 PST 2013


On Mon, Jan 21, 2013 at 11:44 AM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 21/01/2013 17:16, Rick Waldron a écrit :
>
> 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.
>
> I thought more about how I use weakmaps and #1 is a thing I do naturally
> indeed.
> I don't believe in #2, because calls to .has everytime someone may have
> maliciously or by mistake called .clear is quite a cost.
>

Agreed.


>
> I'd like to point out, that just based on what you wrote, you do not
> support the inclusion of WeakMap.prototype.clear, but rather you support
> its non-removal based on what I said.
>

Fair enough!

(I actually laughed a little when I read that)


>  Use cases for WeakMap.prototype.clear are... unclear.
> In which conditions would one want to wipe out all entries?
> If you're the only holder of the weakmap, creating a new one is equivalent
> to .clear (but allows to lazy GC the entries which sync .clear doesn't as
> easily).
>
> More specifically, in which conditions would one want to wipe out all the
> entries they're oblivious to?
>

This is the reality check I can get behind—I'm hard pressed to come up with
a use case that isn't contrived or solvable by some other means.


Rick


>
> David
>
>
>  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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130121/a44381da/attachment.html>


More information about the es-discuss mailing list