From: Paul Brannan <pbrannan@...>
Date: 2002-09-12T04:53:30+09:00
Subject: Re: Multimethods (was Re: Larry Wall's comments on Ruby)

On Thu, Sep 12, 2002 at 03:53:47AM +0900, Hal E. Fulton wrote:
> > Variables in Ruby definitely have types (e.g. "foo" is a String).
> 
> No, "foo" is obviously not a variable. Variables in Ruby
> do not have types.

My mistake.  "foo" is an object.

Dispatching on the types of the variable would be analgous to
dispatching based on the static type of the object.  That's definitely
not desirable for Ruby.

> > References do not have types; they can refer to any Object.
> 
> If there is any distinction in Ruby between a variable and
> a reference, it is a matter for language lawyers, I believe.

Probably not much difference from inside Ruby.  I use "variable" when I
refer to "instance variables" or "class variables" or "local variables."
I use "reference" to refer to the pointer that Ruby uses under the hood
(the VALUE that gets passed around from function to function).

> > > Example: If a method does nothing to its parameter
> > > but invoke the << operator, I might expect that it
> > > would work on strings and arrays. But it would also
> > > work on files, whether I planned that or not.
> > 
> > I think that's a different case, because here you only need to dispatch
> > based on the type of the receiver.  For that, multimethods are probably
> > overkill.
> 
> No, I'm referring to a case where the receiver type is
> fixed, and the parameter type varies.

The receiver of the first method call is fixed; the receiver of <<
varies.  You were able, in this case, to easily divide the operation
into two parts; one on the receiver and one on the parameter.  I'm not
convinced that's always feasible.

I'm also not conviced that multimethods belong as part of Ruby itself;
it seems they might work well in a library.

Paul