js-choi
commented
2 years ago The purpose of mutable cache data structures is key-based random access. In spite of this, sequential access and iteration on CacheMap/CacheSet may still be valuable for debugging and even for user-facing functionality. (This is in contrast to WeakMaps and WeakSets, which cannot reveal their contents without being given a key, by design.)
For example, a developer may wish to view to print the entire contents of a CacheMap at each step of an algorithm.
Additionally, a user-facing application (e.g., a document-editing app) that uses a CacheMap (e.g., a map of temporary, reloadable document data) might have an “activity monitor” or “task manager” screen. This screen may list the document-cache’s contents and which allows the user to purge specific document data.
The ordering of a CacheMap or CacheSet would likely be the order of upcoming purging/removal, rather than insertion order. For example, the keys of a LRU MapCache would first yield its least recently used keys then its most recently used keys. (For FIFO caches, removal order and insertion order would be the same.)
If the CacheMap or CacheSet of an iterator is mutated before the iterator finishes, then its contents’ ordering may dramatically change, depending on its cache policy. In this case, the iterator would likely yield duplicate keys/entries. This is probably fine: Maps’ and Sets’ iterators already may yield duplicate keys/entries when the Maps and Sets are mutated during iteration.
Engine-driven purging in response to memory pressure (#7) would probably still not be a problem for iteration…as long as we make purging occur asynchronously, only between engine jobs (like with WeakMaps and WeakSets). In other words, as long as a CacheMap or CacheSet is fully iterated synchronously, within a single engine job, then the developer should not be surprised by the engine purging keys/entries in the middle of iteration.
Of course, this would also imply that the forEach method should also be present in CacheMap and CacheSet.
Whether the iteration methods should be inherited from Map.prototype and Set.prototype is left to #1.
Should LFUMap, LFUSet, etc. implement the iterable interface? (If not, then they cannot be subclasses of Map and Set (#1).)
If they are iterable, then what should their iteration order be?