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.