Multiple dispatch again

[Carl Banks]

David Mertz wrote:
> I've got to thinking about multimethods/multiple dispatch lately.  I
> wonder if Pythonistas have some futher opinions on the use of these.
> Actually, part of it is that I'd -really- like to better understand use
> cases for multiple dispatch.  As a trick, I can see it has a certain
> elegance, but little rock/paper/scissors toys are not, finally,
> compelling.


I originally conceived the idea of multiple dispatch on my own when
trying to program a video game.  (OO is a good paradigm for video
games because all the characters and blocks and goodies map well to
the concept of an object.)

I wanted an overloaded function that determined what would happen if
two objects collided.  Since the two objects could be any two objects,
it really didn't work with single dispatch.

About the best you could do is define an abstract method collide,
which the derived classes overrides to call a certain method of the
collidee, like this:

    class Bullet: public Object 
    {
        virtual void collide(Object* that) 
        {
            that->be_collided_with_bullet(this);
        }
    }

That was a lot of work, and caused an ugly imbalance.  Half the time,
the be_collided_with_* method simply reciprocated the call; for
example:

    class Human: public Object
    {
        virtual void be_collided_with_bullet(Bullet* that)
        {
            that->be_collided_with_human(this);
        }
    }

Also, I was disturbed by the fact that such calls bypassed data
abstraction, since Bullet and Human would have to be friends for them
to affect each other.  Those were the days when I thought data
abstraction was important.  Still, multiple dispatch could have held
my hand through my period of ignorance and allowed me to define a
single method that could access the private parts of Human and Bullet,
while keeping them well apart otherwise.


-- 
CARL BANKS