From: Joel VanderWerf <vjoel@...>
Date: 2002-09-27T09:03:49+09:00
Subject: Re: adding overload to ruby

bbense+comp.lang.ruby.Sep.26.02@telemark.stanford.edu wrote:
...
>>If 
>>you believe that it is, why don't you believe that the following code 
>>shows that ruby has "typed arguments"
>>
>>
>>  "foo".reverse
>>  [1,2,3].reverse
>>
>>Why do you feel differently about the receiver than about additional 
>>arguments? Multiple dispatch just has more receivers...
> 
> 
> - - Sorry, I don't follow this at all. To me it demonstrates exactly 
> the point I was trying to make. All I need to know is whether you
> can do reverse or not. 

My bad, not clearly explained.

I'm trying to understand why multiple dispatch looks like type checking 
to you, but single dispatch does not.

   "foo".reverse    # ==> "oof"
   [1,2,3].reverse  # ==> [3,2,1]
   7.reverse        # NameError

Does this "look a lot like type checking" to you? I'm guessing not...

Let's suppose that an #append method (or methods) were written that 
dispatched on both arguments, self and "other", and it behaved like this:

   "foo".append "bar"          # ==> "foobar"
   [1,2,3].append [4,5,6]      # ==> [1,2,3,4,5,6]
   "foo".append [4,5,6]        # ==> "foo456"
   "foo".append Proc.new {}    # Exception of some kind

Do you call this type checking? I think the answer is yes, from what you 
said before. But why?

> 
> 
>>BTW, many people would say (and have said) that Ruby is strictly (or 
>>strongly) typed. It's just not statically typed.
>>
> 
> 
> - - Let's put it another way. Multiple dispatch violates the
> principal of object independence. Why does your class need
> to know the internals of my objects? It encourages the 
> creation of fragile code that will fail every time 
> the external environment changes. You're coupling your
> implementation to the details of specific objects.  
> While ruby can't stop you from writing fragile code, it 
> can at least not encourage it. 

Class-based encapsulation is not the only kind. Sometimes algorithms 
need to be decoupled from classes, and encapsulated in a generic function.

More precisely sometimes you have an algorithm that requires defining 
handler methods for various combinations of classes, and it makes more 
sense *not* to expose these individual methods to anyone who is holding 
instances of the classes, but only to expose them as member functions of 
a generic function.

Sigh...  I just can't seem to get over CLOS/Dylan.