Use cases for WeakMap

Erik Corry erik.corry at
Mon May 16 00:08:58 PDT 2011

2011/5/16 Brendan Eich <brendan at>:
> 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?

Are you saying the way that private names work is off limits because
the decision has already been made?

I'd appreciate if you responded to my earlier mail in this thread
where I explained the thinking behind allowing private names on frozen
objects, rather than just saying it's impossible by definition.   In
addition to the reasoning there I will add that if it is possible (and
perhaps it isn't) to satisfy the important use cases of WeakMaps with
a modified private names proposal then we can reduce two new features
to one which AFAICS is a clear win in the
keeping-complexity-manageable effort.

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

The GC properties of weak maps are hard to describe in the standard,
but they are important to the users and the implementers so I hope
they are not off limits for the discussion.

Erik Corry

More information about the es-discuss mailing list