From: Sam Roberts <sroberts@...>
Date: 2003-02-12T00:02:28+09:00
Subject: Re: Operator reordering, good idea? (was Re: ruby-dev summary 19457-19539)

Quoteing akr@m17n.org, on Tue, Feb 11, 2003 at 01:54:11PM +0900:
> In article <20030211044054.GA15912@debian>,
>   Sam Roberts <sroberts@uniserve.com> writes:
> > Actually, I think in general neither should be commutative, they aren't
> > math, they are method calls.
> 
> method call is just a implementation.

It's a fundamental property of the language. When you understand that
operators are method calls, you know how to program in Ruby.

> Do you have any example for == which should not be commutative?

What I'm trying to say is this seems like a special purpose hack. It
*doesn't* make == commutative: it makes == for 3 builtin classes
commutative.

The original example was 

Exception == String

Well, what does this mean? I don't know, what does Exception say it's ==
operator does? An Exception is clearly NOT a string, so at some level
this doesn't make sense, but I guess it defined something reasonable.
If not, I get Object.==, like in ALL OTHER CASES EXCEPT THREE BUILTIN
TYPES.

String == Exception

What does this mean? Well, String.== tries to coerce everything into a
string before comparing itself to it. I know what that means.

Anyhow, I won't bother you guys any more with this.

Cheers,
Sam