I will say that it is quite nice that after the refactoring, things 
like the SqueakMap package loader now use case insensitive sorting.  I 
guess I had gotten used to the default case-sensitive sorting in these 
types of tools, but in retrospect it was pretty horrible. :-)

CaseSensitiveOrder vs AsciiOrder sounds like a more subtle distinction 
(which I haven't looked into at all), but for sorting things like 
selectors, if CaseSensitiveOrder is [foo, fooBar, fooBar:, foo:] and 
AsciiOrder is [foo, foo:, fooBar, fooBar:], then by all means switch it 
to AsciiOrder...

- Doug


On Sunday, April 17, 2005, at 07:56 PM, Martin Wirblat wrote:

> Before we had
> 'a' < 'B' ->  false
> 'A' < 'b' ->  true
>
> which is now
> 'a' < 'B' ->  true
> 'A' < 'b' ->  true
>
> The distinction with case is for sorting 'a' and 'A'
> 'A' compare: 'a' caseSensitive: true -> 1
> 'A' compare: 'a' caseSensitive: false -> 2
>
> I think the old version had hypnotized everyone so that no one 
> complained about lists which have in the middle items which one would 
> expect at the beginning. Yesterday I had to meditate long to see this 
> anomaly as what it really is - a confusing bug - and to remember that 
> I already found it earlier and accepted it with thinking "Squeak is 
> different" :)
>
> >     'foo' < 'foo:'     "true"
> >     'foo:' < 'fooBar'  "true"
>
> was just accidently ok, see
>
> 'foo' < 'foo|'     -> true
> 'foo|' < 'fooBar'  -> false
>
> Items starting with non-alphanumerics were worst. They showed up at 
> the beginning, the middle and the end of a sorted list.
>
> Probably the better sorting algorithm would be to skip every 
> non-alphanumeric. Easier would be to put all non-alphanumerics at the 
> beginning (in CaseSensitiveOrder).
>
> Regards
> Martin
>
> Andreas Raab wrote:
>> Folks,
>> Apparently, I'm the only guy who runs the refactored string stuff ;-) 
>> Or else I would have expected to get a few complaints over strange 
>> method orderings in the browser. It looks like the string refactoring 
>> broke comparison - where before we had:
>>     'foo' < 'foo:'     "true"
>>     'foo:' < 'fooBar'  "true"
>> we now have
>>     'foo' < 'foo:'     "true"
>>     'foo:' < 'fooBar'  "false"
>> which leads to ugly effects in the browser, e.g.,
>>     foo
>>     fooBar
>>     fooBar:
>>     foo:
>> It turns out that the culprit is String>>compare:caseSensitive: which 
>> says:
>> compare: aString caseSensitive: aBool
>>   | map |
>>   map := aBool
>>     ifTrue:[CaseSensitiveOrder]
>>     ifFalse:[CaseInsensitiveOrder].
>>   ^self compare: self with: aString collated: map
>> Turns out that CaseSensitiveOrder is not the same as AsciiOrder as I 
>> expected. Clearly, this is wrong the way it is right now but looking 
>> at it from before the string refactoring it makes me wonder what that 
>> CaseSensitiveOrder was actually good for? It claims it sorts "space, 
>> digits, letters, all the rest" but where is this actually used (e.g., 
>> which applications rely on this ordering)?
>> I'm trying to find this out so that I can fix these things properly. 
>> Speedy feedback would be welcome, otherwise I'll propose to replace 
>> the above with AsciiOrder and your ordering is moot ;-)
>> Cheers,
>>   - Andreas
>
>