Re: Is there any good source for the logic behind some of the methods?

Mark Wilden wrote:
> On May 20, 2008, at 6:20 PM, Michael W. Ryder wrote:
> 
>> I am trying to figure out why methods that seem to do the same thing  
>> behave so differently.  For example Integer("0377") returns 255 as  
>> expected for an octal number but "0377".to_i returns 377.  Or why  
>> Integer("12e3") crashes while Float("12e3") returns 12000.0 as  
>> expected.  I was hoping to find somewhere that tells when to use one  
>> or the other method depending upon expected inputs.  It is very time  
>> consuming to have to keep testing a method to find out it's  
>> limitations.
> 
> I would have to say that very few of us run into this problem,  
> actually. :) Ruby is an agile language, meaning that it doesn't strive  
> for completeness or perfection. It's just a tool to make some customer  
> happy. And in my (and probably others') experience, parsing strings as  
> octal integers simply doesn't arise in very many use cases.
> 
> Which is not to say that I don't think you should explore Ruby just as  
> you're doing. But I've found (through 24 years of programming) that  
> asking "why" isn't generally as fruitful as asking "how." I prefer to  
> start from a need, then figure out how the language will let me  
> fulfill that need; rather than starting by learning all the nooks and  
> crannies of a language that, when all is said and done, was designed  
> by imperfect humans.
> 

My learning project started with a different implementation of the 
Rational module.  While implementing the different methods I was also 
referring to Pickaxe and noted the ending paragraphs on duck typing. 
They mentioned that the programmer should try to expect any input and 
this is what I am trying to implement.  The major difference between my 
implementation and the original was that I allow Strings, Floats, and 
Rationals as input in addition to the original's Integers.
One of the advantages of Object Oriented Programming is that once a 
method is defined inheriting classes automatically have it.  Since 
Integer(x) already allowed for entry of strings with other bases this 
was an advantage to me.  My problem is that Float(x) does not work the 
same way and I was curious as to why.  If I had not been testing 
different possible inputs I would never have found that out, and 
possibly no one else would.
I have been programming for over 35 years and have found that pushing 
the envelope is sometimes necessary to accomplish a task.  I remember 
taking other peoples programs and cutting big pieces out of them and 
replacing them with a couple of lines of code.  Not only did I fix a 
problem with the original program but I made it much easier to maintain. 
  While I could create a method (and have) that handles strings the way 
I expect I don't expect others to be able to understand what I am doing 
at a quick glance and it would be better if I could use existing methods 
the way I expect them to work.
I have nothing against Ruby, it just seemed odd that methods that I 
thought would work the same don't.


> Just some thoughts - not a criticism.
> 
> ///ark
>