Bug after string refactoring

Martin Wirblat sql.mawi at t-link.de
Sun Apr 17 23:56:05 UTC 2005


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
> 
> 




More information about the Squeak-dev mailing list