Bug after string refactoring
Doug Way
dway at mailcan.com
Mon Apr 18 04:28:59 UTC 2005
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
>
>
More information about the Squeak-dev
mailing list
|