Questioning WeakMap.prototype.clear

David Bruant bruant.d at gmail.com
Mon Jan 21 08:44:56 PST 2013


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 
> <mailto: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.

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.
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?

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 <mailto: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/5a17bb95/attachment-0001.html>


More information about the es-discuss mailing list