Use cases for WeakMap

Brendan Eich brendan at
Mon May 16 00:01:08 PDT 2011

On May 15, 2011, at 11:55 PM, Erik Corry wrote:

> 2011/5/16 Brendan Eich <brendan at>:
>> On May 15, 2011, at 3:48 PM, Oliver Hunt wrote:
>>> On May 15, 2011, at 3:47 PM, Boris Zbarsky wrote:
>>>> On 5/15/11 2:20 PM, Rick Waldron wrote:
>>>>> Thanks Brendan, I was looking for something that was representative of
>>>>> Boris's use-case
>>>> A typical example is an extension wanting to associate some state with a DOM element or a Window without polluting the DOM.  For example, Adblock Plus wants to store some state per-element so that it knows when it's in the middle of unblocking something so it'll allow the load through for that one thing only.  Firebug wants to store some state per-window (e.g. script bodies, etc) and discard it when the window goes away.
>>> Which is a use case private names would achieve much more succinctly than weakmaps.
>> Not if the object is frozen.
> That shouldn't prevent you adding private names.  See earlier message
> in this thread.

Now we are going in circles. Let's try to use words already defined in ES5 and model things in observably distinguishable ways, or what's the point?

Frozen means [[Extensible]] is false, so you can't add any properties, I don't care how they are named. What you are proposing here is not observably different from soft fields via weak maps. That is one way to "implement private names" but it isn't what we have been calling "private names", and it does not help the discussion to assume one conclusion.

Further, some controversy remains around reflection. If any party (one with access to the private name) can reflect on a private-named extension to a frozen object, the objejct was therefore not really frozen, rather extensible.

>> Unless you then overspecify private names *as* weak maps, in which case we are going in circles :-P.
> Allowing private names on frozen objects doesn't imply the GC
> semantics of weak maps so there is still a very important difference.

Not observable.

Anyway, inextensible objects cannot be decorated with new properties, whatever the privacy or GC semantics of those properties' names.


More information about the es-discuss mailing list