A newbie question about case and ===

[Sonny Chee]

Hey Guys,

Let me apologize upfront if this is not the appropriate place to ask
newbie questions. I can repost, if someone can point me to the correct
location.

Assuming no is offended, my question is:

I read that the case statement uses the === method for comparison of
each of its clauses. So, why doesn't the second comparison in the
following code snippet evaluate identically?

a_fix_num = 1
puts a_fix_num.class
case a_fix_num
when Integer
puts 'Yes, this is an Integer subclass'
else
puts 'No, this is not an Integer subclass'
end

if a_fix_num === Integer
puts 'Yes, this is an Integer subclass'
else
puts 'No, this is not an Integer subclass'
end

# Fixnum
# Yes, this is an Integer subclass.
# No, this is not an Integer subclass.

Sonny.

 

[Eero Saynatkari]

Hey Guys,

Let me apologize upfront if this is not the appropriate place to ask
newbie questions. I can repost, if someone can point me to the correct
location.

Assuming no is offended, my question is:

I read that the case statement uses the === method for comparison of
each of its clauses. So, why doesn't the second comparison in the
following code snippet evaluate identically?

a_fix_num = 1
puts a_fix_num.class
case a_fix_num
when Integer
puts 'Yes, this is an Integer subclass'
else
puts 'No, this is not an Integer subclass'
end

if a_fix_num === Integer
puts 'Yes, this is an Integer subclass'
else
puts 'No, this is not an Integer subclass'
end

case actually evaluates the other way.

Integer === a_fix_num # true

# Fixnum
# Yes, this is an Integer subclass.
# No, this is not an Integer subclass.

Open up a terminal and type in ri Class#===
(and play around with ri otherwise too

 

[Just Another Victim of the Ambient Morality]

case actually evaluates the other way.

Integer === a_fix_num # true

That is hilarious!
It's obvious when you think about it but, otherwise, it's very
surprising...

 

[gwtmp01]

case actually evaluates the other way.

Integer === a_fix_num # true

I think the problem is that the visual representation (===)
of the operator i symmetric and this tends to imply that the
operator follows associative behavior ((a op b) the same as
(b op a)) but that isn't true for === in general.

If the operator token was asymmetric I don't think it would
be so confusing. Actually, I wonder why the match operator (=~)
couldn't be used instead. I've looked into this a bit, but I
I suspect that there are very few cases where === and =~
could not be aliases for each other.

Gary Wright

 

[Sonny Chee]

case actually evaluates the other way.

Integer === a_fix_num # true

Thanks Eero!