I've known about this for a little while and figured I should let
people know and get feedback on my plan to fix it.
Ever since I added typecasting to Sequel (on May 21, 2008), Sequel has
used the strict typecasting methods Kernel#Integer and Kernel#Float
for typecasting, instead of the looser ones like #to_i and #to_f. For
floats, this works fine, but for integers, this causes a problem when
leading zeros are used, as the default behavior of Kernel#Integer is
to treat an initial zero as a radix indicator, specifying an octal
(base 8) number:
$ ruby -e "p Integer('08')"
-e:1:in `Integer': invalid value for Integer: "08" (ArgumentError)
from -e:1
or worse:
$ ruby -e "p Integer('017')"
15
This hasn't bit me personally yet, but I've probably just been lucky.
I didn't know about the radix handling in Kernel#Integer when I
originally added the typecasting feature.
I think it a good idea to change this. Unfortunately, changing it
would break backwards compatibility for anyone relying on the
feature. I'm not sure anyone is, but if you are, please speak up. If
so, I'll probably provide an extension for backwards compatibility
that preserves the existing behavior. I do feel the current default
is problematic enough that it is worth breaking backwards
compatibility.
I plan on committing a change in the next version to fix this issue.
On ruby 1.9, Kernel#Integer takes two arguments, the second being the
radix to use, so on 1.9 I plan to just use "Integer(s, 10)". On 1.8,
it looks like string manipulation is the only way: "Integer(s.sub(/\A0+
(.)/, '\1'))".
Does this sound reasonable to everyone?
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
