In article <3D80AD8D.27388.FBF0F18 / localhost>,
Pit Capitain <pit / capitain.de> wrote:
>On 12 Sep 2002, at 21:14, dblack / candle.superlink.net wrote:
>
>> > As Matz pointed out overloading would be in the spirit of Ruby
>> 
>> Right, but that's the part I don't get :-)  I'm picturing things like:
>> 
>>   def meth(Integer n, String s)
>>   ...
>>   def meth(Float f, String s)
>>   ...
>> 
>> and somewhere along the line I'm not clear on how that fits into the
>> spirit/design/philosophy of Ruby.
>
>David, as I understand it, of course you would still be able to do
>
>  def meth(f, s)
>
>which would be equivalent to
>
>  def meth(Object f, Object s)
>
>Only if you wanted to have a different behaviour dependend on the 
>types of the arguments you would do something like
>
>  def meth(Integer n, s)
>  def meth(Float f, s)
>
>So it really would be an addon to current Ruby, not breaking any 
>existing code.
>

I'm kind of torn between the two sides on this one...

Currently if we need a method that does two different things based on 
the type of an argument we have to do:

  def meth(s)
    case s
    when Integer
      #do something
    when Float
      #do something else
    end
  end

It _would_ be nice to be able to declare two meth methods as shown above 
instead of having to test the type of the argument.

However, I also agree with David that this could change the nature of the 
language.  I also suspect that there will be a performance 
hit for all code even if you don't use method overloading.  IF it could be 
implemented in such as way as to not impact performance if you don't use 
the feature, then I'd probably lean towards doing it.  

Phil