tilly wrote:

You have not convinced me that designs that rely on MMD are a good idea. Particularly not in a language like Perl where the way people usually use the language will lead to people expecting you not to do that.

Hmm, that's a rather interesting way of putting it. Let's play with the wording a bit and see if we can clear that up, shall we?

You have not convinced me that designs that rely on closures are a good idea. Particularly not in a language like Java where the way people usually use the language will lead to people expecting you not to do that.

While certainly not an exact quote, that's pretty darned close to a rebuttal a Java programmer gave me in response to my arguments about the merits of closures. No offense Ben, but those two sentences are orthoganal to each other. Just because people aren't used to X doesn't mean that X is not a good idea.

Now that we have that out of the way, let's consider MMD. MMD should not be overused, but when it's necessary, it simplifies the code and is a better solution than a bunch of similarly named methods or forcing the programmer to write code to simulate it. However, MMD and proper argument processing go hand-in-hand, so much of the following assumes we're talking about both.

For example, if you look at how dispatch tables are frequently implemented in Perl, you'll find that they're often used to dispatch on type. Thus, the programmer has to write some code similar to this:

my %dispatch = (
  Foo => \&_foo,
  Bar => \&_bar,
  Baz => \&_baz,
);

sub process {
  my ($self, $thing, $data) = @_;
  my $type   = ref $thing || '';
  my $method = $dispatch{$type} || die "Can't find method ...";
  $self->$method($data);
}
[download]

That, of course, it ugly, but it's a lot less ugly than the faux switch statements or if/elsif/else chains people come up with (and less error prone, too). To compare with MMD:

multimethod process (Foo $thing, String $data) { ... }

multimethod process (Bar $thing, String $data) { ... }

multimethod process (Baz $thing, String $data) { ... }
[download]

Not only is that shorter, it's more likely to be correct. Forcing me, the programmer, to write code to handle a common idiom that so many modern languages never have to worry about is silly. Heck, how many times have we seen the following bug?

sub name {
  my ($self, $name) = @_;
  $self->{name} = $name if $name;
  return $self->{name};
}
[download]

Now, if you need to clear someone's name, it's very difficult to do. That bug is virtually impossible to write when using MMD. What a beautiful thought. An entire class of bugs eliminated. (Of course, MMD introduces a completely different class of bugs, but in my experience, they bite far less often.)

And let's not forget that MMD potentially allows compiler optimizations that aren't possible when dealing with all of the potentiall buggy programmer alternatives. And while we're on the topic of optimizations, notice that traditional Perl code requires two sub calls for the dispatching instead of one. Perl's subs are slow enough that this could be a significant performance bottleneck on some systems. I've been hit by this and working around it can be very painful.

However, let's take a look at my dispatch code. If I want to add an extra event, I add another entry to the dispatch table. But what happens when someone does this?

Oopsie. The code silently fails. Perl's poor argument handling strikes again! However, if I need to actually allow that, my dispatch code can get awfully ugly. With MMD, that can easily throw a nice, fatal error, letting the programmer know that no such method exists. Otherwise, I just write another method. Nice and easy either way.

And while we're thinking about argument handling, I see (and have written) plenty of code which doesn't verify the number arguments to a method. In fact, this is a debate that regularly comes up in the Perl community: how much sanity checking is required? Many hackers do very little checking and, if we're really lucky, they have test suites to catch stuff. Some put sanity check everything and then moan in horror about how slow their system is.

Guess why Java programmers don't debate this too much? Because, ironically enough, in the case of MMD and proper argument handling, they have the language doing something that the programmer shouldn't be forced to do.

PS: When you show up for OSCON, let me know and I'll buy you a beer. Or you can buy me one. Or four. I know how to dispatch them properly.