From: Rich Kilmer <rich@...>
Date: 2002-09-13T05:41:20+09:00
Subject: RE: not grasping the method overloading/multi-dispatch thing

About a year ago there was a thread on method overloading based on
types.  The thread can be viewed in Google here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&th=7a93426d7
ff5c81&rnum=175

the final message from Harry Ohlsen was:
____

At this point, I think the mechanism is sufficiently straighforward that
I'd just consider it a programming idiom. Ie, I wouldn't even bother
having a separate class, nor adding an Array#types.

I think that 

   def fred(*args)
      case args.collect { |a| a.type}
         when [Float, Fixnum, String]
              f, i, s = args
              # ...

is sufficiently clear that it stands by itself.

I think this has been a particularly wonderful thread.  It's a really
nice example of taking an idea and moulding it until it feels right (at
least to me).
___

-rich

> -----Original Message-----
> From: Albert Wagner [mailto:alwagner@tcac.net] 
> Sent: Thursday, September 12, 2002 4:23 PM
> To: ruby-talk ML
> Subject: Re: not grasping the method overloading/multi-dispatch thing
> 
> 
> On Thursday 12 September 2002 01:40 pm, Phil Tomson wrote: <snip>
> > 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.
> 
> My 2 cents:  When I find that I am testing type, as above, 
> then it usually 
> means that it's time to refactor.  Then you can have two 
> methods with the 
> same name, but in different classes, where they belong.
> 
> >
> > 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
> 
> 
>