Skip to content


Subversion checkout URL

You can clone with
Download ZIP


WeakMap, Set, Map #69

petermichaux opened this Issue · 7 comments

4 participants


Of all the things I fight against in JavaScript programming, it is the loss of architectural possibilities that hurt the most due to the lack of WeakMap, Set, and Map.

WeakMap is essential for having caches that won't prohibit garbage collection. As it stands now, you'd have to implement your own mark and sweep system in your app code in order to release objects no longer needed.

Set and Map are thing we cannot do now in general with performance better than O(n) for set.has(obj). The versions of Set and Map we can implement now always have limitations in order to have better performance, usually O(1) for set.has(obj).

All three of these have been kicked around and are in or Harmony. I hope browser makers will move things along faster than the standards process.


This is really important, in particular the Map is absolutely necessary (we could get away with a set being a map to boolean if maps worked properly). I did raise this myself as issue 63 not that long ago, but it was closed with the argument that it's solved in harmony as is.


@petermichaux I agree completely - but as you say there are already harmony proposals

The idea of JSFixed (maybe not made clear) is to propose a delta (things to add and things to remove) on top of the TC39 proposals

I'll close this unless you object


Ok. I misunderstood that JSFixed was also to reinforce what real developers want rather than what spec writers want or think developers want.


Speaking from a non-computer science background, what's the difference between a map and a weak map? The Harmony wiki doesn't do a very good job of clarifying that.

Maps are similar in style to weak maps but without the funny garbage collection semantics or non-enumerability.

What's the significance of the different garbage collection semantics?


When a garbage collector runs, it does not want to collect objects the program still needs. If a globally findable object has a (strong) reference to another object then that other object cannot be garbage collected. If a globally findable object has a weak reference to another object then that object can be garbage collected.

Having a weak map makes it possible to keep caches of model objects around, for example, but the cache will allow a model object in the cache to be garbage collected if the cache is the only thing with a (weak in this case) reference to the model object.


@petermichaux Very helpful. Thank you!


Glad I held off closing this - otherwise we wouldn't have got that gem of a summary by @petermichaux :-)
(there is nothing as succinct in es-discuss)

Closing now.

@angus-c angus-c closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.