Hi,

On Mon, Jan 17, 2005 at 12:32:08AM +0900, trans.  (T. Onoma) wrote:
> Since Ruby doesn't support signature-based method definitions, what good does 
> it do to throw errors on the wrong number of arguments? Seems to me, this 
> just makes the programmers job more difficult. What if Ruby nil'd unspecified 
> parameters and ignored extra parameters. Eg.
> 
>   def ameth(a,b)
>     a.to_i + b.to_i
>   end
> 
>   ameth         #=> 0
>   ameth(1)      #=> 1
>   ameth(1,2,3)  #=> 3

   rggh! Please don't. This is the Perl way, and I've had some good
headaches because of this, while refactoring code.

> Perhaps there is a problem with doing this that I don't see, but it's more in 
> line with Ruby's dynamic behavior. Testing is were such errors should be 
> caught, if indeed these are errors. This is the standard explanation one gets 
> about duck-typing after all. Why wouldn't it apply here as well? And it's not 
> like it can't be done either. As it stands, to achieve the same effect I must 
> conceive of it a bit differently as:
> 
>   def ameth( *args )
>     args[0].to_i + args[1].to_i
>   end
> 
> So it's not like it should not be done. We do it all the time.

   But, IMHO, that's a pretty _rare_ need. If you need that, you can use
"*args" (as you say) or perhaps use optional parameters. But once you don't
raise an error when calling a method with an unexpected number of arguments,
you have _no automatic check_ for _most_ (again, IMHO) cases.

   Regards,

-- 
Esteban Manchado VeláÛquez <zoso / foton.es> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es