From: Tim.Hunter@...
Date: 2002-09-13T05:40:56+09:00
Subject: Re: not grasping the method overloading/multi-dispatch thing

In Phil's example, it seems like "meth" is testing the argument's
class, not its type. According to my copy of _Design Patterns_, the
type of an object is the set of methods to which it can respond. If
two objects respond to the same set of methods then they have the same
type, even if they aren't objects of the same class.

For me, testing an argument's class is a code smell. What do I care if
"s" is a Foo or a Bar, as long as it responds to the methods I need to
send it? I try to design my classes and methods so that, if I want
method "A" to accept as arguments objects that are created from
different classes, then each of the classes should implement the set
of methods that "A" will send. As far as "A" is concerned, all the
objects have the same type.

So, for the case where you want to "overload" concat to accept EITHER
String objects or Fixnum objects:

	concat("A", "B") -> "AB"
	concat("A", 1) -> "A1"
	concat(1, 2) -> "12"

then you define concat as

def concat(arg1, arg2)
	arg1.to_s + arg2.to_s
end

Since both String and Fixnum objects respond to to_s, they're both the
same type as far as concat is concerned.

On 12 Sep 2002 17:57:41 GMT, ptkwt@shell1.aracnet.com (Phil Tomson)
wrote:

(snip)
>
>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