Questioning WeakMap.prototype.clear

David Bruant bruant.d at
Tue Jan 22 07:01:16 PST 2013

Le 22/01/2013 15:19, Jason Orendorff a écrit :
> On Tue, Jan 22, 2013 at 5:56 AM, David Bruant <bruant.d at 
> <mailto:bruant.d at>> wrote:
>     Le 22/01/2013 11:47, Jason Orendorff a écrit :
>>     On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruant.d at
>>     <mailto:bruant.d at>> wrote:
>>         [...] WeakMap.prototype.clear questions the property that was
>>         true before its adoption ("you can only modify a weakmap
>>         entry if you have the key")
>>     David, would you please elaborate your argument for this
>>     invariant? This the first I've seen it stated.
>>     An invariant can be a powerful thing. Still, I guess my default
>>     position is that (1) the object-capabilities perspective is only
>>     one view among many; (2) even looking at things with an eye for
>>     o-c integrity and security, clearing a data structure seems like
>>     a reasonable thing to allow, treating a reference to the data
>>     structure itself as a sufficient capability. It's (2) that I
>>     would especially like you to address.
>     I think Rick already suggested your (2), though phrased a bit
>     differently [1] (that was his #1). I answered [2]: "I thought more
>     about how I use weakmaps and [well-encapsulate my weakmaps so that
>     I'm the only holder] is a thing I do naturally indeed."
>     The problem may arise when you start sharing weakmaps around and
>     some use cases require you to [3].
> What problem exactly?
I was wrong in saying "*the* problem". A problem may arise, this problem 
being that there is a risk that you were relying on some entries and 
that they may disappear at any time making your code harder to reason about.

> Also, I don't understand how [3] is a use case for sharing weakmaps 
> around. To me it looks like a use case for clearing a WeakMap.
I was imagining that some of the different phases could be performed by 
third-party code. But since the use case is about a cache, there is no 
reason one would rely on the existence of some entries. Maybe a more 
subtle use case needs to be found.

> Sharing mutable data structures across abstraction (or trust) 
> boundaries is already pretty well understood to be an integrity (or 
> security) risk. It's easy to fix: you expose a read-only view instead.
If WeakMap.prototype.clear is part of the built-in API, an attacker 
(including buggy code) can do, 
so "exposing a read-only view" means wrapping pretty much the way Mark 
Miller implemented clear

     class WeakMapWithoutClear {
         private let wrapped;
         constructor() {
             wrapped = new WeakMap();
         get(key) => wrapped.get(key),
         set(key, val) => wrapped.set(key, value),
         has(key) => wrapped.has(key),
         delete(key) => wrapped.delete(key)

What this and my previous show is an semantics equivalence between 
clearable and clear-less weakmaps. Which should be chosen as default?
* clear-less weakmaps have better integrity properties.
* clearable weakmaps may have better performance characteristics (I'm 
still not entirely convinced)
Are use cases for .clear that common that they justify being put in the 
native API? Or is it acceptable to ask those who want it to wrap in classes?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list