Re: Why Object#class Is Inconsistent in "==" and "case"?

Dear Mr. Dave Thomas,

Thank you, thank you very much for your very clear explanation.  The
rationale is such convincing that now it is very difficult for me to think
the other way around.

To tell you the truth, Ruby is such a natural and fun language that even
one small bite is very painful; this is because my expectation has become
so high, I guess.

Probably things like this are good to be put in your next second edition
of the book (for some people, the rationales are much more interesting
than just knowing what are implemented because the rationales will make us
think further and become better programmers), or probably it is a good
idea to come up with a book on the interesting and peculiar features of
Ruby (something like "C Traps and Pitfalls")?  I guess the book will not
be too thick.  Compared to other languages, Ruby by far is the cleanest,
except for one or two bites from time to time, which are very few as
compared to other languages.

I have used Python before, but I switched to Ruby because the people at
Python often could not come up with good answers with Python peculiar
features; it is more like dogma there.

Regards,

Bill
============================================================================
Dave Thomas <[e-mail]> wrote:
> Why is it that way? So you can write:

>    case user_input

>    when "stop"
>       exit

>    when /help (.*)/
>       do_help($1)

>    end

> Each comparison can be against a different object type, and use a
> different comparison operator (string comparison in the first case,
> regexp in the second).
.....
> Because "fred" === "fred" and /fred/ === "fred", but "fred" does not
> === /fred/. Remember that === is just a method call: in your
> particular case you want to override Object#=== to work with
> Modules. But what happens if someone else wants it to be the same as
> Range#===, or Regexp#===. It's just not a reversible or symmetrical
> mapping.
.....
> Dave