Before my re-entry in JavaScript (and related) I've done lots of ActionScript 3 and there they had a Dictionary object that had weak keys, just like WeakMap introduced with ECMAScript 6; but the AS3 version still was enumerable like a regular generic object while the WeakMap specifically has no .keys() or .values().
The AS3 version allowed us to rig some really interesting and useful constructs but I feel the JS version is somewhat limited. Why is that?
If the Flash VM could do it then what is keeping browsers from doing same? I read how it would be “non-deterministic” but that is sort of the point right?
Before my re-entry in JavaScript (and related) I've done lots of ActionScript 3 and there they had a Dictionary object that had weak keys, just like WeakMap introduced with ECMAScript 6; but the AS3 version still was enumerable like a regular generic object while the WeakMap specifically has no .keys() or .values().
The AS3 version allowed us to rig some really interesting and useful constructs but I feel the JS version is somewhat limited. Why is that?
If the Flash VM could do it then what is keeping browsers from doing same? I read how it would be “non-deterministic” but that is sort of the point right?
Share Improve this question edited Jan 2 at 14:32 dumbass 27.2k4 gold badges36 silver badges73 bronze badges asked Dec 11, 2013 at 1:07 BartvdsBartvds 3,5005 gold badges33 silver badges42 bronze badges 8- 8 I think the MDN entry sums it up pretty well: "Because of references being weak, WeakMap keys are not enumerable (i.e. there is no method giving you a list of the keys). If they were, the list would depend on the state of garbage collection, introducing non-determinism." It's not that rules couldn't be defined, but by not allowing the operation to begin with the implementations (of which there are several competing) can side-step the issue entirely. – user2864740 Commented Dec 11, 2013 at 1:10
- Sure, that makes some sense but it a little weak (hehehe) of the standard committee. I'm still hoping for some insight on why ennumerability is not important enough to be a required feature. – Bartvds Commented Dec 16, 2013 at 19:46
- 2 @bernstein you don't. The weak map is intended to be used for cache implementations and things like that, where other parts of your application know about keys that might be in the map. – Pointy Commented May 17, 2014 at 15:37
- 2 What? No it is not. This is not about the basic Map, but is a very specific Weakmap question. The referred item doesn't answer the question, just like other answers here it ignores the fact that the AS3 version worked fine with non-determinism. – Bartvds Commented Jun 23, 2014 at 14:51
- 1 @Pointy The fact that the key must be an object and must not be a primitive data type, makes it impossible for most use cases to use the WeakMap as a cache. A web cache uses URLs (a string) and DAO classes use OIDs (integer) as keys for the cache. Both use cases are impossible with objects as keys. – ceving Commented Nov 4, 2015 at 13:04
2 Answers
Reset to default 21Finally found the real answer: http://tc39wiki.calculist.org/es6/weak-map/
A key property of Weak Maps is the inability to enumerate their keys. This is necessary to prevent attackers observing the internal behavior of other systems in the environment which share weakly-mapped objects. Should the number or names of items in the collection be discoverable from the API, even if the values aren't, WeakMap instances might create a side channel where one was previously not available.
It's a tradeoff. If you introduce object <-> object dictionaries that support enumerability, you have two options with relation to garbage collection:
Consider the key entry a strong reference that prevents garbage collection of the object that's being used as a key.
Make it a weak reference that allows its keys to be garbage collected whenever every other reference is gone.
If you do #1 you will make it extremely easy to to shoot yourself in the foot by leaking large objects into memory all over the place. On the other hand, if you go with option #2, your key dictionary becomes dependent on the state of garbage collection in the application, which will inevitably lead to impossible to track down bugs.