It appears to be an issue of precedence. Typing this in irb, I get:
irb(main):001:0> p (1…4).type
1…4
NilClass
…suggesting that the type call binds to the result of the p call. This
works as expected on 1.7.2, but you really should write it
p((1…4).type) to remove ambiguity.
Unable to reproduce this problem on both
ruby 1.6.6 (2001-12-26) [i586-linux-gnu] and
ruby 1.7.2 (2002-07-13) [i686-linux] so I can’t help you on that one,
sorry…
···
–
([ Kent Dahl ]/)_ ~[ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 4. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
The ‘real’ problem for me is that:
[…]
raises exception for ‘uid = 997’
Well, my real problem is that I’m just heedless … uid = “997”, just
because it comes from ARGV
But the ‘p (1…4).type # => (1…4)’ remains mystery for me …
What’s happening is that it’s being parsed as:
(p (1…4)).type
So the ‘p’ part happens (you see (1…4)), and .type is evaluated
silently.
I have to say I haven’t gotten the hang of exactly how/when/why Ruby
does one thing and not the other. I do know that it changed between
1.6.7 and 1.7.x, so you get: