Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10267
| Newsgroups | comp.lang.java.programmer |
|---|---|
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
| Subject | Re: case insensitive sort |
| References | <nfvoc7t69mjhbed81u75k9v1j1nn4pcu73@4ax.com> <4ed04e65$0$289$14726298@news.sunsite.dk> |
| Message-ID | <slrnjd1tig.fvg.avl@gamma.logic.tuwien.ac.at> (permalink) |
| Date | 2011-11-26 14:23 +0000 |
Arne Vajhøj <arne@vajhoej.dk> wrote: > On 11/23/2011 12:06 AM, Roedy Green wrote: >> When someone asks for a case insensitive sort, they typically use code >> like this in the Comparator >> return a.x.compareToIgnoreCase( b.x ); >> However than will not give you what you really want. You probably >> want this if you want tidy-looking results. >> int diff = a.x.compareToIgnoreCase( b ); >> if ( diff != 0 ) return diff; >> return a.x.compareTo( b.x ); > > Assuming that whoever asked for a case insensitive sort did not mean > it but wanted a case insensitive sort with those case insensitive equal > sorted case sensitive. Which I consider a pretty safe bet in practise. From a javadoc-link quickly googled: " The natural ordering for a class C is said to be consistent with equals " if and only if (e1.compareTo((Object)e2) == 0) has the same boolean value " as e1.equals((Object)e2) for every e1 and e2 of class C. Note that null " is not an instance of any class, and e.compareTo(null) should throw a " NullPointerException even though e.equals(null) returns false. " It is strongly recommended (though not required) that natural orderings be " consistent with equals. This is so because sorted sets (and sorted maps) " without explicit comparators behave "strangely" when they are used with " elements (or keys) whose natural ordering is inconsistent with equals. In " particular, such a sorted set (or sorted map) violates the general " contract for set (or map), which is defined in terms of the equals method. This is just another example of where a comparability based only on compareNoCase is likely a bad thing. > It is certainly possible that it is what they want, but in > general developers should not change requirements to what they > think the requirements really are. Roedy's hint was probably targetted to those who do define the detail requirements themselves.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-22 21:06 -0800
Re: case insensitive sort Patricia Shanahan <pats@acm.org> - 2011-11-22 21:59 -0800
Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-23 06:34 +0000
Re: case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-23 02:49 -0800
Re: case insensitive sort Roedy Green <see_website@mindprod.com.invalid> - 2011-11-23 02:46 -0800
Re: case insensitive sort Patricia Shanahan <pats@acm.org> - 2011-11-23 05:23 -0800
Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-23 19:32 +0000
Re: case insensitive sort dibs <dibs@dobs.dabs> - 2011-11-23 15:11 -0500
Re: case insensitive sort v_borchert@despammed.com (Volker Borchert) - 2011-11-24 05:03 +0000
Re: case insensitive sort Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:26 -0500
Re: case insensitive sort Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-26 14:23 +0000
Re: case insensitive sort Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:56 -0500
Re: case insensitive sort Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-04 10:43 +0000
csiph-web