Asp Forum - case equality question

Phil Meier

7/24/2007 9:56:00 AM

Hello

I do not understand the following code:

======
file = File.open('test.txt', 'r')
hash = {'file' => file, 'title' => 'title'}
hash.map { | param_key, param_value |
puts "param_key = #{param_key}"
puts "param_value = #{param_value}"
puts "(param_value === String) = #{(param_value === String)}"
case param_value
when String
puts "This is a String!"
when File
puts "This is a File!"
else
puts "Neither String nor File!!!"
end
}
file.close
===

When I run this code the output is as follows:
param_key = title
param_value = title
(param_value === String) = false
This is a String!
param_key = file
param_value = #<File:0x2b689b8>
(param_value === String) = false
This is a File!

Why does Ruby goes to the when String case even if (param_value ===
String) is false?

BR Phil

13 Answers

F. Senault

7/24/2007 10:00:00 AM

Le 24 juillet 2007 à 11:55, Phil Meier a écrit :

> Why does Ruby goes to the when String case even if (param_value ===
> String) is false?

I've been very suprised with this recently, but...

>> 'a' === String
=> false
>> 1 === String
=> false

>> String === 'a'
=> true
>> String === 1
=> false

Fred
--
It's a hard work, being a network pusher. Your customers beep you in
the middle of the night, hungry for another fix. But, what can you do ?
Customer satisfaction and all that crap...
Pays good, though. (Ingvar the Grey in the SDM)

Sebastian Hungerecker

7/24/2007 10:10:00 AM

Phil Meier wrote:
> Why does Ruby goes to the when String case even if (param_value ===
> String) is false?

Because it checks whether String===param_value and not param_value===String.

HTH,
Sebastian Hungerecker.
--
NP: Green Carnation - When I Was You
Ist so, weil ist so
Bleibt so, weil war so

dblack

7/24/2007 10:10:00 AM

dblack

7/24/2007 10:12:00 AM

Kaldrenon

7/24/2007 1:57:00 PM

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.

Rob Biedenharn

7/24/2007 2:28:00 PM

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://agileconsult...
Rob@AgileConsultingLLC.com

Sebastian Hungerecker

7/24/2007 2:29:00 PM

Kaldrenon wrote:
> Hm...I'm not sure I like that it doesn't go the other way.

Wouldn't work.

> b === a checks if a is-a b, right?

Only if b is a class. If b is e.g. a range or an array, it checks whether b
includes a. If b is a regex it checks whether b matches a. For many other
things it's just the same as b==a.

> 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

There's always .class, but that doesn't help you unless you assume that the
argument passed to === will always be a class, which it won't.

--
NP: Explosions in the Sky - Magic Hours
Ist so, weil ist so
Bleibt so, weil war so

Kaldrenon

7/24/2007 2:42:00 PM

On Jul 24, 10:28 am, Sebastian Hungerecker <sep...@googlemail.com>
wrote:
> Only if b is a class. If b is e.g. a range or an array, it checks whether b
> includes a. If b is a regex it checks whether b matches a. For many other
> things it's just the same as b==a.

Okay, that's a more logical way of thinking about it, thank you. See,
I was looking at === as equivalent to Java's instanceof keyword, but I
can see now that that's not all === does.

Thanks for helping me clear it up.

dblack

7/24/2007 3:45:00 PM

a-little-sanity, please

12/10/2010 12:49:00 AM

In article <Xns9E4A5042D2D9ulmbritwarcouk@69.16.176.253>,
Periander <ulm@.4rubbish.britwar.co.uk> wrote:

> ... in your view were significant numbers of deaths at the camps
> attributable to starvation diets, illness brought about by typhus and
> similar diseases, over work, black marketeering and the like by the
> kapos ... and so on.

As I replied already, the number of deaths from these
factors was very small compared to the number of those
gassed upon arrival.

> I say that the deaths from the above causes, illness especially
> was the major cause of death in the camps.

What you say is contradicted by all the existing evidence. The
major cause was plain murder. Yet again:

"The accused shall not be punished because of the actions
against the Jews as such. The Jews have to be exterminated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and none of the Jews that were killed is any great loss. Although
the accused should have recognized that the extermination of
^^^^^^^^^^^^^^^^^^^^
the Jews was the duty of Kommandos which were set up especially
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for this purpose, he should be excused for considering himself
^^^^^^^^^^^^^^^^
to have the authority to take part in the extermination of Jewry
himself." -- from the verdict of the Supreme SS and Police Court,
in the case of SS-Untersturmfuehrer Max Taubner, 24 of May 1943.
Quoted from "The Good Old Days", E. Klee, W. Dressen, V. Riess,
The Free Press, NY, 1988, pages 196-207.

Now, tell us what you know that the SS officers acting
as judges in the Supreme SS and Police Court in 1943 didn't
know. Don't be shy now, old boy. Do tell us.

comp.lang.ruby

case equality question

Phil Meier

F. Senault

Sebastian Hungerecker

dblack

dblack

Kaldrenon

Rob Biedenharn

Sebastian Hungerecker

Kaldrenon

dblack

a-little-sanity, please

x Login to ForumsZone