tilly wrote:

Much of what you've just said for multi-method dispatch by type works perfectly well already in Perl if you're dispatching by class using OO. Arguing for how great multi-method dispatch would be using examples where OO dispatch suffices is not going to convince me.

I'm not sure I follow you here. Are you suggesting that in examples like I provided, the invocants be in different classes? Whenever possible, I really like to minimize the number of classes and creating a new class just to handle a different argument type to a method frequently does not make sense. One example of this would be the constructor:

my $parser1 = Some::Parser->new($string);
my $parser2 = Some::Parser->new($uri_object);
my $parser3 = Some::Parser->new($fh_object);
[download]

In that example, with three constructors, each taking a different argument type, we can still return objects in the same class. Class-based dispatching wouldn't make sense there. Did I misunderstand what you were saying?

Dan Sugalski points to event driven code where different objects generate events and your event handlers are a series of methods whose arguments are the objects generating the events. I shouldn't push the event handling into the objects themselves because they shouldn't care how they're going to be used. Instead, I have a simple GUI class which knows that it's supposed to handle events. This is a common Java idiom and it works very well.

The main problem I have with MMD is I am frequently more interested in the interface an object provides rather than its type/class.

Oh, and you'll see that I'm not the one who used the getter/setter example. While it's a reasonable example that fits well with many people's coding styles, I also prefer different names there because the methods are doing different things. When the methods are conceptually doing the same thing, they should have the same name, if possible.

Update: Whoops! I guess I did use a getter/setter example :)