From: Rob Biedenharn <Rob@...>
Date: 2007-07-24T23:28:11+09:00
Subject: Re: case equality question

On Jul 24, 2007, at 10:00 AM, Kaldrenon wrote:
> Hm...I'm not sure I like that it doesn't go the other way. I like it
> when code is easily converted to plain speech, when a line can be read
> across quickly. And this seems to break that. Maybe not, but here's
> how I see it:
>
> b === a checks if a is-a b, right? Well isn't it a lot easier to read/
> write/say "A is a B" than "B is instantiated in A" or "An example of B
> is A"? Maybe this is a semantic quibble, but since English speakers
> (and consequently a majority of the programming community) read left
> to right, wouldn't it make more sense to have it behave this way?
>
> It wouldn't even necessarily break case statements, since the .===
> method would be part of all of the basic type classes (Fixnum/String/
> etc) and there's always .class
>
> This is just my opinion, and I admit to not knowing a lot yet. But I
> figured I'd voice my thoughts.

case some_obj
when String
   # do String stuff with some_obj
when 50..100
   # do number stuff with some_obj
end

Perhaps you just need to think of different language when you want to  
"read" the code:

"When String recognized some_obj, do String stuff with some_obj; when  
the range 50 to 100 recognizes some_obj, do number stuff with some_obj."

The way in which Class constants (like String or Fixnum) recognize  
(apply ===) happens to be an "is a?" test is happy arrangement.

You could even go further and read that as:

"Focus on some_obj and when String recognizes it, ..."

To distinguish the "case expr when obj" from the "case when expr"  
form that is much closer to an "if-elsif-else" construct.

-Rob

Rob Biedenharn		http://agileconsultingllc.com
Rob@AgileConsultingLLC.com