Not grasping the method overloading/multi-dispatch thing

ruby-talk
1

I see this as a big advantage to the language.

  1. Overloading doesn’t break a great language. It just enhances it. Ruby
    would still retain everything that makes it neat.

  2. It allows for “cleaner” solutions where overloading is the “best” option.
    It could be argued that overloading is needed to satisfy POLS. If Ruby is
    truly the best OO language, how can it not have overloading!! :slight_smile:

  3. If Ruby is ever to be JIT-compiled, knowing a parameters type has
    advantages for performance since code can be optimized.

···

On Thursday, September 12, 2002 8:25 AM, dblack@candle.superlink.net wrote:

On Thu, 12 Sep 2002, Pit Capitain 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 :slight_smile: 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.

True, it wouldn’t break code, but it would (for me) completely change
the “feel” of Ruby. Also, I think we’d start to see very little of
this:

def meth(n)

and lots and lots of this, even where it wasn’t necessary:

def meth(Integer n)

I think the availability of this kind of thing would deter many people
from exploring what is unique about Ruby.