Andreas Raab wrote:
...
> 
> My point (to repeat it, hopefully making it clearer now) is that for a 
> case-*sensitive* comparison I used the so-called CaseSensitiveOrder, 
> assuming that this would basically be equivalent to plain AsciiOrder. 
> But it isn't, and the comparison provided by Case*Sensitive*Order can 
> hardly be called case-*sensitive*.

Andreas,
it is case-sensitive, just in a different manner than you expected.

'A' < 'a' is true if #< is defined like it is now:

< aString
     ^(self compare: aString caseSensitive: true) = 1

if < = > <= >= were like

< aString
     ^(self compare: aString caseSensitive: false) = 1

'A' = 'a' would be true.


Now we have:

'A' < 'a'
'A' < 'b'
'a' < 'B'

That's way better than the old ordering. The alternative
(self compare: aString caseSensitive: false) would give

'A' = 'a'
'A' < 'b'
'a' < 'B'

I think for sorting purposes this is the best version. Especially the 
non-programmer is irritated by 'B' < 'a' (old version) and in a longer 
list 'Az' < 'aa' (current version) is similar confusing.

The problem is that a programmer might expect 'A' = 'a' to be false. But 
the comment of #= says:

"Answer whether the receiver sorts equally as aString....

What about using

(self compare: aString caseSensitive: false)
   for #< #<= #> #>=

and

(self compare: aString caseSensitive: true)
   or even real array equality for #=

That would sort fine, but it would make both 'a' <= 'A' and 'A' <= 'a' 
true from which one could follow that 'a' = 'A' which would be false. 
There may be other problems.

Perhaps the current version is a compromise of sorting somewhat sensible 
and having a String equality similar to Array equality  #($A) ~= #($a)

Regards
Martin