Questioning WeakMap.prototype.clear

Jason Orendorff jason.orendorff at
Tue Jan 22 06:19:33 PST 2013

On Tue, Jan 22, 2013 at 5:56 AM, David Bruant <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> 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?

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.

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.

Thanks for the response.


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

More information about the es-discuss mailing list