For unordered keys in a key sequence, KeyHasher could sort its hashes before serializing them (CollectionConfiguration)

[ajvincent]

All the composite sets I've built treat the set keys as an ordered tuple. If the end-user wants unordered sets (say, Set([1, 2]) == Set([2, 1])), then the only way to do that would be to sort the hashes KeyHasher provides before serializing them.

That would have to be a configuration setting which doesn't exist right now.

[ajvincent]

The same could apply for map keys. We might want map.get("blue", "yellow") === map.get("yellow", "blue") by having the map key hasher sort its hashes first.

[ajvincent]

OTOH, we might want

map.get("red", "yellow", "blue") === map.get("red", "blue", "yellow")
map.get("red", "yellow", "blue") !== map.get("yellow", "blue", "red")

This might be built at the KeyHasher level (maybe a bootstrap class) in conjunction with #51.

[ajvincent]

CollectionConfiguration.prototype.markKeysUnordered(...keys)

• The keys array must have length greater than 1
• Weak key + strong key disallowed
• Map key + set key disallowed

[ajvincent]

• [ ] exports/UnorderedStrongStrongMap
• [ ] exports/UnorderedStrongStrongSet
• [ ] exports/UnorderedWeakWeakMap
• [ ] exports/UnorderedWeakWeakSet

[ajvincent]

CollectionConfiguration will probably need a key manager class specifically to handle unordered keys and linked keys, after key definitions are complete.

[ajvincent]

Something to consider: argument validation could interfere here, particularly if the validators do something different based on their position.

This might be a Hard Problem to solve via static analysis tools. Probably it would be easier to just document for developers this "gotcha", so they don't run into this.

[ajvincent]

Nope, not happening.