|
| 1 | +# @wry/key-set-map |
| 2 | + |
| 3 | +Whereas the `@wry/trie` package associates values with _sequences_ of keys, the |
| 4 | +`@wry/key-set-map` package and its `KeySetMap` class provide a similar |
| 5 | +capability for _sets_ of keys, so the order of the input keys is no longer |
| 6 | +important. |
| 7 | + |
| 8 | +As with a traditional [Trie](https://en.wikipedia.org/wiki/Trie), lookups and |
| 9 | +insertions take linear time in the size of the input set, and peek-like |
| 10 | +operations can often bail out much more quickly, without having to look at all |
| 11 | +the input set elements. |
| 12 | + |
| 13 | +Since JavaScript `Set` and `Map` containers maintain insertion order, two |
| 14 | +equivalent sets (containing identical elements) can nevertheless be detectably |
| 15 | +different if their keys were inserted in a different order. Deciding which of |
| 16 | +the orders is "correct" or "canonical" is a fool's errand, possible only when |
| 17 | +there is an inherent total ordering among the elements, suggesting a |
| 18 | +sorting-based strategy. |
| 19 | + |
| 20 | +Because sorting is tempting as a strategy for turning sets into |
| 21 | +canonically-ordered sequences, it's important to stress: this implementation |
| 22 | +works without sorting set elements, and without requiring the elements to be |
| 23 | +comparable. In fact, the lookup algorithm is asymptotically faster than it would |
| 24 | +be if the keys had to be sorted before lookup. |
| 25 | + |
| 26 | +Finally, to avoid taking any position on which ordering of elements is |
| 27 | +canonical, this implementation never grants direct access to any previously |
| 28 | +provided sets. Instead of attempting to return a canonical `Set`, the keys of |
| 29 | +the set are associated with an arbitrary `TData` value, which is all you get |
| 30 | +when you look up a set of keys. |
| 31 | + |
| 32 | +## Memory management |
| 33 | + |
| 34 | +When `WeakRef` and `FinalizationRegistry` are available, the `KeySetMap` class |
| 35 | +automatically reclaims internal memory associated with sets containing keys that |
| 36 | +have been garbage collected. |
| 37 | + |
| 38 | +To that end, when keys can be garbage collected, the `KeySetMap` takes care not |
| 39 | +to retain them strongly, acting like a `WeakMap` for object keys and like a |
| 40 | +`Map` for non-object keys. In other words, `KeySetMap` does not prevent its |
| 41 | +(object) keys from being garbage collected, if they are otherwise eligible. |
| 42 | + |
| 43 | +By passing `false` for the `weakness` parameter to the `KeySetMap` constructor, |
| 44 | +you can disable weak-key-related functionality, so the `KeySetMap` will behave |
| 45 | +like a `Map` for all keys, regardless of whether they are objects or primitive. |
| 46 | +This mode is not encouraged for production, but may be useful for testing, |
| 47 | +debugging, or other diagnostic purposes. |
| 48 | + |
| 49 | +Any `TData` objects allocated by the `KeySetMap` may outlive their associated |
| 50 | +sets of keys, and retaining a strong reference to the `TData` object by itself |
| 51 | +does not prevent garbage collection and removal of object keys. However, as long |
| 52 | +as all keys remain reachable and are not removed from the `KeySetMap` with |
| 53 | +`remove` or `removeSet`, the set of keys will remain in the `KeySetMap` and thus |
| 54 | +retain a reference to the associated `TData`. |
0 commit comments