From: Justin Johnson <justinj@...>
Date: 2002-09-12T04:18:00+09:00
Subject: Re: Multimethods (was Re: Larry Wall's comments on Ruby)


> Variables in Ruby definitely have types (e.g. "foo" is a String).
> References do not have types; they can refer to any Object.

"foo" is a string object.

A Ruby variable references an object, be it "foo", nil, 123456, whatever.
In Ruby, they are all treated as objects.

> The example that Andrei Alexandrescu gives in _Modern C++ Design_ is
> ....

We experienced the dispatch example with collision detection in our game
software, so I can vouch for it's real world validity.  If I remember
correctly, we solved it using STL maps.  The final solution felt
unsatisfactory, though it worked fine.

> I haven't finished reading the book yet, so I can't share much more than
> that.  But it's turning out to be a very good read.

It's a good book, and he's a clever guy.  I wouldn't like to maintain large
programs with this much power template usage though.  There are some
spectacular gymnastics to achieve things that you take for granted in
dynamically typed languages.  Like Ruby. :-)

I'd be interested to see if anyone could come up with some satisfactory
syntax with regards to implementing multi-dispatch in Ruby.

--
Justin Johnson


"Paul Brannan" <pbrannan@atdesk.com> wrote in message
news:20020911133900.A25425@atdesk.com...
> On Thu, Sep 12, 2002 at 01:26:42AM +0900, Hal E. Fulton wrote:
> > In any case, I wouldn't favor adding this to Ruby,
> > as variables have no types; and thus how do you
> > define a method "signature"?
>
> Variables in Ruby definitely have types (e.g. "foo" is a String).
> References do not have types; they can refer to any Object.
>
> > What's more, a method with a single parameter can
> > be passed an object of ANY type. I'd hate to define
> > a method for each type I expected (as I would in
> > C++ or Java), especially since that would preclude
> > types I *didn't* expect.
>
> The example that Andrei Alexandrescu gives in _Modern C++ Design_ is
> a game in which you have a method that gets called when two objects
> collide, and you want to have different behavior when a ship collides
> with an asteroid, or a ship collides with a space station, or an
> asteroid collides with a space station.  (he actually borrowed this
> example from Scott Meyers).  In C++, we dispatch based on:
>   1) the dynamic type of the receiver (or static type if the function is
>      non-virtual)
>   2) the static types of the parameters
>
> Ruby doesn't have static types, so it doesn't dispatch on the static
> types of the parameters (thus it does not have C++-style overloading).
> I think what multimethods would give you is dispatching on the dynamic
> types of the parameters.  In the game example, this would avoid having
> to write a single function that knows about asteroids and space ships
> and space stations (since that function would break if we were to add a
> fouth type).
>
> I haven't finished reading the book yet, so I can't share much more than
> that.  But it's turning out to be a very good read.
>
> > 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.
>
> Paul
>
>