On Wed, Oct 16, 2013 at 11:23 PM, Gilles <gil...@harfang.homelinux.org>wrote:
> Consequently, the lexicographic comparator will definitely be slower since > it > will needlessly spend time ordering the values. Yeah if value's compareTo() is expensive, this could hurt. Here, for an Integer value it's going to be a rounding error compared to memory movement. I think. I question the correctness of the change in "sortInPlace" (with the above > argument), and the immediate usefulness _for_ CM (since a user interested > in a pair functionality should probably use Lang's implementation). > You did not expose your use-cases so I cannot judge whether a user would > have reasons to prefer CM's implementation. If you're right that this stretch of code doesn't care about ordering of values, then it can't be wrong-er, merely slow-er, to bother ordering by value. Right? My point was only that the correctness worry can't be a reason against this change. (In the abstract, java.util.Comparator says you need to compare on values too if equals() does, and we hope this code never changes to subtly depend on this correctness, but right now it doesn't seem to.) I thought it went without saying that the use case is external callers. The single potential internal usage it was just a potential bonus. Is it beyond CM's scope to include a little utility class? meh, I hadn't thought so but I can see that point of view, and that alone is good enough for me. It's just bike-shedding beyond this point.
