Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data iteration and order #3

Open
js-choi opened this issue Mar 31, 2022 · 1 comment
Open

Data iteration and order #3

js-choi opened this issue Mar 31, 2022 · 1 comment
Labels
question Further information is requested

Comments

@js-choi
Copy link
Collaborator

js-choi commented Mar 31, 2022

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?

@js-choi js-choi added the question Further information is requested label Mar 31, 2022
@js-choi
Copy link
Collaborator Author

js-choi commented Aug 20, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant