Jean-Denis Muys
2/13/2009 1:12:00 PM
On 2/13/09 1:00 AM, "ruby-talk-admin@ruby-lang.org"
<ruby-talk-admin@ruby-lang.org> wrote:
> From: Yossef Mendelssohn <ymendel@pobox.com>
[...]
>>
>>>>> "1.8.9" > "1.8.8"
>>> => true
>>
>>>>> "1.8.10" > "1.8.9"
>>> => false
>>
>> I remember the discussions. I stand by my assertion that this is a bug.
>
> I don't know about the discussions relating to this behavior, but I
> find it dismaying that anyone would seriously say that this isn't
> desired string comparison behavior. I mean, these are *strings*, not
> anything special. They just happen to contain a certain pattern of
> characters.
>
Well, I am seriously suggesting just that.
And I am not alone. The Mac Finder will "alphabetically" list files named
1.8.8, 1.8.9 and 1.8.10 in that order.
Moreover, in MacRuby, I can do:
>> framework 'Cocoa'
=> true
>> a="1.8.8"
=> "1.8.8"
>> b="1.8.9"
=> "1.8.9"
>> c="1.8.10"
=> "1.8.10"
>> a.compare b, options:NSNumericSearch
=> -1
>> b.compare c, options:NSNumericSearch
=> -1
Before you point it out, yes, the NSNumericSearch constant option must be
passed to compare for that to work that way. Without it, compare returns the
result you expect.
My point is that we programmers have grown to expect string comparison to
work in the incorrect way, to the point that you now claim that the
*desired* behaviour is the wrong one. My claim is that the *desired*
behaviour is for "1.8.10" to sort after "1.8.9". My mother and my
grandfather agree.
And no, I don't suggest we redefine string comparison in Ruby at this point
in time.
As for the issue at hand, a good solution was proposed.