j.t.Collator is basically for locale sensitive sorting, and I think this
use case is locale independent. Aside from how significant to have it in
the library, I am not sure j.t.Collator is the right place.
Naoto
On 12/16/14 11:04 AM, Xueming Shen wrote:
On 12/16/2014 06:58 AM, roger riggs wrote:
Hi Ivan,
In which package/class do you propose to add the API to get the
comparator?
In java.time, comparators are returned from static methods in an
interface.
This allows lambda to be used for the implementation.
For example, ChronoZonedDateTime.timeLineOrder
<https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
For example a static method could be added to CharSequence:
public static int Comparator<CharSequence> alphaNumericComparator() ...
In use it would be
CharSequence.alphaNumericComparator().compare("012", "234");
This is more like a special case of j.t.Collator. I'm not sure it's a
good idea to put this "special"
comparator into CharSequence, without careful planning. I will assume
there are more useful
utility comparators people would like to see here. To use the original
example, while the
it's good to have this comparator to compare "jdk 10" and "jdk9", how
about "jdk-10" and
"jdk 9"? Yes, it is more like a collator:-)
-Sherman
