Michael W. Ryder
5/22/2008 4:22:00 AM
Mark Hubbart wrote:
> Michael W. Ryder wrote:
> [snip]
>> If I use Float("17") it returns 17.0 and Float(0x11) returns 17.0, both
>> as expected. Why doesn't Float("0x11") work? As Ruby doesn't appear to
>> handle Floats of bases other than 10 (or at least I haven't figured out
>> how to yet) I can see it choking on Float("0x11.34") but it shouldn't
>> choke on Float("0x11").
>
> Actually, this is probably the most logical behavior. Integer() and
> Float() have the same defined behavior; they both can accept one of two
> inputs:
> 1. A Numeric that can be converted into the correct type;
> 2. A String that can be parsed into the correct type.
>
> If a string is provided, then it must follow the same rules as the
> appropriate literal representation.... This is the source of the
> differences. So:
>>> Integer("023") #=> 19
>>> Float("023") #=> 23.0
>>> Integer("0x23") #=> 35
>>> Float("0x23") #=> ArgumentError!!!
>>> Integer("1e3") #=> ArgumentError!!!
>>> Float("1e3") #=> 1000.0
>
> To make them truly cross-compatible would eliminate the error-checking.
>
I am glad to see that I am not the only one that feels this way.
>> Part of what I am doing is trying to follow the statement in Pickaxe
>> about duck typing and programming for any input, not just a select
>> subset.
>
> Beware of doing *too much* duck typing. Figure out a reasonable point to
> stop. Unless there's a significant amount of value added by allowing
> strings, I wouldn't do it. If you can think of a reasonable circumstance
> where the programmer would want to pass a string instead of an actual
> number, go ahead; otherwise, it' just bloat, and bloat is a great source
> for bugs :)
One of the nice things about Ruby is that a lot of the code necessary to
cast a variable to another type is already there so for the most part it
was very simple to add support for additional types of input. Along the
way I learned about other things like handling exceptions, and hunting
down some of the "bugs" in converting inputs is where I found some
things that I feel are inconsistencies. Since this project is more for
my benefit, as there already exists a rational module, I am not too
worried about code bloat except when it occurs to handle unexpected
behavior in the language.