@mjtsai I rewrote using 2 tables, a weak-to-weak + strong-to-weak, but from my experimentation, it seems strong-to-weak has the same limitation. Also, the `count` property is different from key/objectEnumerator.allObjects.count when content is zeroed.
@cparnot Yes, doesn’t this make sense? Or would you prefer to release the object when the key disappears? IMHO that wouldn’t exactly qualify as “strong”, but I can see use for this.
@p2@cparnot Yes, removing the weak key should remove the strong reference to the object. Otherwise, your map will leak. Strong refers to the fact that the map retains the object for as long as it contains the (valid) key.
@mjtsai (1) Yes, `removeObjectForKey:` properly releases the key/object in both weak-to-strong, or strong-to-weak. But you have to do it before zeroing happens…
@mjtsai (2) Zeroing the (weak) object or key, does not immediately release the (strong) key or object, and the entry is *gone* and can’t be reached anymore via the public APIs (not sure about `removeForKey:` actually).
@mjtsai Yes, it leaks (until NSMapTable is reallocated or until it purges those entries, e.g. after resizing or some other unknown internal event; if you don’t touch the NSMapTable and keep it alive, it stays as-is forever).
@cparnot The documentation is not very clear. I would expect it to retain the key until you remove it but for that entry not to show up in the enumerator or count.
@mjtsai Ah, I see the logic, though I would expect to behave more like the weak-to-strong for symmetry… In any case, it does eventually “purge” the keys, from what I see.
@mjtsai And to be clear, when the object is zeroed, `objectForKey:` does return nil for that key. It’s just that the key is retained for a while longer. And `count` returns a useless value.