From: Eric Hodel <drbrain@...7.net>
Date: 2005-07-07T02:36:02+09:00
Subject: Re: Object#=~

On 06 Jul 2005, at 10:06, Eric Mahurin wrote:

> --- Eric Hodel <drbrain@segment7.net> wrote:
>
>> On 06 Jul 2005, at 09:30, Eric Mahurin wrote:
>>
>>>> <dooby@d10.karoo.co.uk> writes:
>>>>
>>>>> I expected you to say that this was intentionally provided as a  
>>>>> "third state":
>>>>>
>>>>> true  - positive pattern match result
>>>>> nil   - negative pattern match result
>>>>> false - don't know (no match was done)
>>>
>>> Should nil be don't know and false be mismatch?  That would be
>>> consistent with <=> which returns nil if the items aren't
>>> comparable.  Maybe the same should be done with == and ===
>>> return nil instead of false when the 2 objects can't be
>>> compared.
>>
>> $ ruby -e 'p "f" =~ /x/'
>> nil
>
> "f" vs. /x/ are comparable so I was thinking false might be
> more  suitable than nil.

This would not be a backwards compatible change.  daz's suggestion  
simply defines a convention for existing behavior, which feels much  
better to me.

> And use nil when it is the wrong type
> of object or doesn't respond to the right methods.  I'm
> suggesting that comparison operator methods look something like
> this:
>
> def ===(obj) # or <=>, ==, =~
>     return(nil) if obj isn't comparable to self
>     ... compare returning false instead of nil ...
> end

Where in Ruby are two objects not comparable via #=== or #==?

#<=> is used by Comparable, and nil makes sense there because it gets  
called on the inside.  I've rarely called #<=> by itself.

#=~ only needs to return false values when there's no match, and true  
values when there is a match.  I don't see what making it match up  
with the other three gains anyone.

-- 
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04