From: Alan Moore Date: 2001-10-16T15:15:55+09:00 Subject: [ruby-talk:22597] Why is String#oct so special? Hi all, Does anyone else find the behavior of String's "oct", "hex", and "to_i" methods confusing? (I'm not talking about the business of returning zero on failure; I know that's been discussed here before.) This graph shows the results when these methods are called on strings containing verious forms of the decimal number thirteen: string oct hex to_i ------------------------------ "13" 11 19 13 "0x0d" 13 13 0 "0b1101" 13 725249 0 "015" 13 21 15 "+ 13" 11 0 0 Why is that, of the three methods, only oct notices if the string looks like a hex or binary number and converts it accordingly? It seems to me that, if only one of the methods is going to be that smart, it should be to_i, since it gets no hint about what it's looking at. In fact, though, I think they should all be able to recognize the various integer formats, just like the Ruby parser itself does. Then, if (for example) oct is called on a string that starts with "0x" or "0b", it should fail, since it obviously isn't looking at an octal number. Also, as the last row of the table shows, oct permits white- space after the sign, but I think that's just a bug. Note that oct quits being so smart when it's dealing with negative numbers: string oct hex to_i ------------------------------ "-13" -11 -19 -13 "-0x0d" 0 -13 0 "-0b1101" 0 -725249 0 "-015" -13 -21 -15 "- 13" -11 0 0 All this inconsistent behavior makes Ruby a lot harder to use than it needs to be, IMHO. (It also makes it harder for me to re-create these methods in JRuby ^_^) At the very least, all three methods should parse the string in the same way. --Alan p.s.: About those return values, why not have the methods return nil on failure? Then you could write if (num = str.to_i) { ... } ...and it would work, since zero is true and nil is false. Just a thought.