Questioning WeakMap.prototype.clear

Mark S. Miller erights at
Tue Jan 22 07:18:00 PST 2013

On Tue, Jan 22, 2013 at 2:47 AM, Jason Orendorff
<jason.orendorff at> wrote:
> 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;

Of course.

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

In general, yes. Maps exist as simply a useful mutable container data
structure. .clear is perfectly reasonable to allow on maps, and indeed
neither I nor anyone I recall has raised any objections to this.

But WeakMaps were introduced specifically to support rights
amplification[1]. Because of this special need for WeakMaps, we
introduced them first. The Maps and Set strawmen came later. Since the
get/set/has/delete functionality of WeakMaps and Maps seem naturally
related, we proceeded considering them to be related -- both by name
of the abstraction and by compatibility of their common methods. This
still seems attractive to me. But this type-like relationship between
them seems to be causing more confusion than clarity. Their purposes
are very different.

[1] <> has a good
explanation of rights amplification, and shows the purse example as an

> Cheers,
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at


More information about the es-discuss mailing list