Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #10267

Re: case insensitive sort

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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