Perhaps I'm just having trouble following the thread, but I see MMD the other way around. MMD's job is to make it easy to have subroutines which are concrete and unambiguous.

I think what tilly is getting at is that MMD can, from a certain perspective, make it harder to see what code is going to be executed.

This is a general problem as we add more ways of breaking up and abstracting the code. For example with this code:

do_stuff($x, $y);
[download]

With no modules we know, just by looking at the call, that do_stuff() is defined in this file. We have one place to look, and we can only affect what do_stuff() does by changing that subroutine (or the stuff that subroutine calls).

use Foo;
...
do_stuff($x, $y);
[download]

As soon as we add modules do_stuff() could come from the current file or Foo.pm. Now we have two places to look for do_stuff(), but at least it's only defined in one place.

use Foo;
...
$foo->do_stuff($x, $y);
[download]

Now that we've added objects we need to look at the class of $foo, the name of the method and understand the way the class hierarchy is searched for methods, before we can figure out that it could be defined in Foo.pm, or any of the ancestors of Foo.

Indeed with calls to SUPER:: what do_stuff() does could be split over several different files and subroutine definitions, and changing any of them could affect what this call does.

use Foo; # build with MMD
...
$foo->do_stuff($x, $y);
[download]

Now with MMD we need to know the classes of $foo, $x and $y, their respective parent classes and understand a more complex method ordering function, before we can be certain of where the bit of code associated with this call lives.

We have the problem that changing the class hierarchies of the objects in $foo, $x and $y, or adding different variants of do_stuff() can potentially change the ordering of the methods and so change what this particular call to do_stuff() does.

The recent spirited discussions on method ordering functions that have been happening on perl6-language are an example of how tricky this can be.

These are, I think, the kind of problems that make tilly question the utility of MMD.

---

That said, I like MMD and want it in Perl :-)

Why aren't I worried? Several reason.

I spent some time using MMD when I wrote code in Lisp/CLOS some years back. The vast majority of the time it all just worked. While there are many possible routes for unexpected things to happen, they're not a common occurrence in practice as far as I'm concerned. So my experience using MMD took away a lot of my fear.

Another reason I like MMD is that I find breaking down program flow using polymorphism less susceptible to bugs than breaking down program flow with if/then statements. Since I'm lazy I'd prefer the compiler write my despatch code rather than do it myself. It will probably do a better job and, since it's part of the language core, people won't have to learn what it does.

The most insidious problem that I encountered was that occasionally changing code changing the method ordering and broke existing code. I'm no longer frightened of that because I produce all my code test-first in small incremental steps. So any problems of this sort will rapidly show up in test failures, which I know will be associated with the last change that I made.

So, taken on the whole, I find MMD enables me to remove complexity rather than add it in.