You're right, I hadn't realized that the spec forbade primitives as WeakMap keys - so while to approach should actually work in other languages, in JS it would leak memory as you'd be forced to use a normal map (or clean up after yourself - ich).
Yeah weakmap and weakset basically do the opposite of what I want. The keys are weakly held rather than the values, which does no good for an ORM cache. One cannot even iterate over the keyset in a weakmap (so you can't do a lousy o(n) lookup version of what I want.
Actually WeakMap() could not be iterated over as its keys are not enumerable by design - you can't "know" at any given time what the list of keys actually contains.
You and I had this exact conversation at Eataly a few months back. WeakMaps are cool, but JS is a garbage-collected language. All you have to do to GC something is stop referencing it.
WeakMaps are only really useful when you don't control the referenced object's lifecycle. Even then, you can simply invert your map or check in your callback.
If you've got enough keys that it matters you probably want to use a `Map` instead of an object? Maps are faster to write and read is approximately the same.
Again, this is something that is simple to learn and understand. And you would learn this in a beginner tutorial. Why go through trouble to change it and complicate the language even further? I undeerstand weakmap may have some real advantage as far as GC, at least.
WeakMap also works really well for that, because it means you don't add any extra properties or symbols to the object itself. Instead you store it in the WeakMap with the object as a key, and it'll still get garbage collected with the object as if you'd added it to the object. I've found it's occasionally useful when you're trying to get things from different frameworks to interact with each other, both of those frameworks want to do things like assigning extra fields or setting up proxies, and then they start conflicting.
I was confused by his description of WeakMap, because I hadn't looked at the spec in a while. For reference, the reason why it's not applicable to the task at hand is because it's not primarily meant to have the values weakly referenced. Rather, it's meant to not lock the keys in. I'm not sure what he means by "best used to link objects together". WeakMap simply allows you to keep data about an object outside of it and without keeping it from being freed when it's not needed anywhere else.
If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys.
I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.
The weak keys is nice as it gives you a place to put "hidden" properties that can only be accessed when combining an object and the WeakMap. When the object is GC'd, the hidden properties in the WeakMap can as well.
But you can get close using a naming convention on the objects proper, say double underscore prexix or whatnot.
What can't be easily approximated right now is weak values, for identity maps in particular.
That’s more about [@@iterator] not being a thing on IE11 rather than anything about Map. There’s still Map.prototype.forEach, which is entirely sufficient.
Also, iteration is not the only purpose of Map; its real value is that you can use keys of any type, and I’ve used Map and WeakMap a number of times without having needed any form of iteration—e.g. avoiding polluting every element I need to track data on (MY_DATA: Symbol; Element[MY_DATA]: MyData), maintaining a WeakMap<Element, MyData> instead.
Not quite. First, a map from a WeakRef to a value wouldn't do anything useful, since a WeakRef's target dying does not magically blow away the WeakRef itself. Second, you would have no way of getting from an object to its WeakRef(s), so you couldn't do a lookup anyway. But those criticisms are unfair; you're just using loose language to mean a map whose entries hold their keys weakly and values strongly.
But it's not that either. If it were that, and your key died but your map didn't, then the value would still be kept alive. And it doesn't hold both key and value weakly; in that case, you could have both map and key alive and yet the value could die; WeakMaps won't allow that.
It's something subtly different. It's a collection where both the key and map have to be live for the WeakMap entry to keep the value alive. "Weak" in the name is something of a misnomer, in my opinion. Weak normally means "something that can refer to an object without keeping it alive". WeakMap entries are not weak, they are normal strong references that very much keep their values alive -- but only if both the map and key are both alive.
Nice! I have used Maps often for storing arbitrary key-value pairs, but until 5 minutes ago I didn't know you could use object references as keys. So this was a very good use of 5 mins.
I said it _doesn't_ give you enough power to justify the baggage, apologies if I wasn't clear. Iteration/modeling is one of my gripes in fact. The only way to copy a map is a for loop, really?
reply