Use cases for WeakMap

Brendan Eich brendan at
Mon May 16 10:30:20 PDT 2011

On May 16, 2011, at 12:43 AM, Erik Corry wrote:

>>> Elided for clarity :-)  It can be implemented with private names or
>>> WeakMaps.
>> Oh, ok -- you wrote "normal JS object" and that seemed to preclude new stuff.
>> Yes, we can make a value -> value map as a library abstraction, but it's clunky. It has to use two kinds of maps under the hood. People shouldn't necessarily have to reinvent or discover or curate it and download those bytes all the time.
> This is where we disagree fundamentally.

First, it helps to be clear about present vs. future tense -- we may not disagree at all once we straighten that out.

Second, of course we on TC39 are trying to fill semantic gaps, minimally and compositionally. We are not out to standardize libraries and higher-level abstractions in general. I've spoken and written about this often.

This is why generators are in harmony, while schedulers and deferreds built on them (or built on extensions to them, or on underlying models such as CPS conversion, but that's not the only way...) are not yet in Harmony.

It's arguably also why classes have had such a hard time.

Anyway, we don't disagree fundamentally on such short notice, with recent lack of clarity in tense and terms.

> I think we should give
> people the lego bricks to build the abstractions they need.  You seem
> to think we should give them all the abstractions  they are going to
> need, ready built.

Not at all, see above and please don't exaggerate. Here, in this thread, I raised the question of value -> value maps not being fully considered:

> This is a good point too. Not sure we've considered a value -> value map carefully yet.

It's still worth building the library code and weighing it. Your ellipses left out a lot.

> As for downloading all the time that's a caching/modules/libraries
> issue which needs to be solved in other ways.

Agreed in general, but we have Map and Set on the agenda for the meeting next week. We've standardized library code such as the Array extras in ES5. De-jure cleanup and codification of de-facto standards such as Function.prototype.bind are on our permanent agenda.

> The context was you talking about a value->value map.
> I presented a value->anything map which was implemented as a 'normal object'.
> You complained it wasn't an anything->anything map.

No, I thought you were suggesting it could be implemented without weak maps or something like them -- that's all.

> I said you could do that with either private properties or weak maps.
> At that point you need both the 'normal object' and something else.


> Perhaps we have a nomenclature problem with 'value'.  Do you regard
> things that have typeof(o) == 'object' as values?


Let's get back to the observable-per-spec differences between private names (as proposed and called by that phrase in TC39) and other things based on WeakMaps, which may or may not (I think not) be competing with private names as proposed.

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

More information about the es-discuss mailing list