From: William Djaja Tjokroaminata Date: 2002-04-13T02:58:13+09:00 Subject: 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 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