Affects Version/s: Backlog
Fix Version/s: None
Patch:Code and Test
Excerpted from Mark Engelberg's message of July 14, 2010 in that discussion thread:
It will only be possible to properly implement subseq on priority maps with a patch to the core. subseq achieves its polymorphic behavior (over sorted maps and sorted sets) by delegating much of its behavior to the Java methods seqFrom, seq, entryKey, and comparator. So in theory, you should be able to extend subseq to work for any new collection by customizing those methods.
However, the current implementation of subseq assumes that the values you are sorting on are unique, which is a reasonable assumption for the built-in sorted maps which sort on unique keys, but it is then impossible to extend subseq behavior to other types of collections. To give library designers the power to hook into subseq, this assumption needs to be removed.
1. A simple way is to allow for dropping multiple equal values when subseq massages the results of seqFrom into a strictly greater than sequence.
2. A better way is for subseq to delegate more of its logic to seqFrom (by adding an extra flag to the method call as to whether you
want greater than or equal or strictly greater than). This will allow for the best efficiency, and provide the greatest possibilities for future extensions.
Note: subseq currently returns () instead of nil in some situations. If the rest of this idea dies we might still want to fix that.
Patch clj-428-code-v5.patch implements approach #2 above. It preserves the current behavior of returning () instead of nil.
Patch: clj-428-code-v5.patch tests in clj-428-tests-v5.patch