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.
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:)
"Eero Saynatkari" <eero.saynatkari@kolumbus.fi> wrote in message
news:f6a9600f8e87240669e788b674456558@ruby-forum.com...
Sonny Chee wrote:
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
That is hilarious!
It's obvious when you think about it but, otherwise, it's very
surprising...
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
···
On Aug 28, 2006, at 9:02 PM, Eero Saynatkari wrote: