From: Stephen White <spwhite@...>
Date: 2001-06-27T07:51:42+09:00
Subject: [ruby-talk:16938] Re: Method overloading (option) Was: Re:

On Wed, 27 Jun 2001, Yukihiro Matsumoto wrote:

> It's OK for me to open up new RCR.  But to tell the truth, I feel like
> that explicit dipatch based on type is not a Ruby-way(TM).

Besides, defining multiple functions with the same name uses the same
amount of space as writing a case statement.

  def call(Integer a)
  end

  def call(String a)
  end

  def call(Float a)
  end

~=

  case a.type
    Integer
    String
    Float
  end

and has the same meaning anyway. I'd rather modify a list of items in
a case statement than a list of function declarations. The case list is
grouped together, the declarations can appear anywhere.

In any event, dispatching based on type is a static typing kind of thing
to do, and having to explicitly code it out in Ruby does serve as a hint
to do something different.

For Ruby to support static typing as well as dynamic typing would mean
writing two parallel infrastructures. Code that communicates through
defined methods (now) and code that communicates through type systems.

Now how does code organised by types talk to code organised by methods?
You could rewrite, but how do you tell one library to talk to another
library when one dispatches on types and the other calls by method?

Eg, a library that dispatches on types would stop me doing things like:

  class Whatever
    def puts *args
    end
  end

then making a call to the library... since it will no longer recognise
what is being passed to it, whereas a Ruby library will just make the
call to my defined version of puts.

Both ways have their advantages and their problems, but to put in support
for both ways limits us to the overlap between the two. Ruby derives part
of its power from providing only a few very good tools. The fewer tools
used, the easier code is to work with.

--
  spwhite@chariot.net.au