From: Eric Mahurin <eric_mahurin@...>
Date: 2005-07-07T03:15:49+09:00
Subject: Re: Object#=~

--- Eric Hodel <drbrain@segment7.net> wrote:

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

both are changes and both could cause compatibility issues.  I
think either way causing a compatibility issue would be rare,
although I have to admit the unknown==nil/mismatch==false would
probably be more likely.  unknown==nil and mismatch==false
seems more natural and if a change is going to be made it might
as well be done right.

> > 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 #==?

1=="hi"
(1..4)==="hi"

These return false right now, but I think unknown/nil is better
to distinguish from these cases (which are also false):

1==0.0
(1..4)===5

For most other methods, the first case where you are doing
something with an incompatible object results in an exception. 
I think returning nil for equality operators makes sense for
that case.



		
____________________________________________________
Sell on Yahoo! Auctions � no fees. Bid on great items.  
http://auctions.yahoo.com/