Dispatch ambiguity can really bite you, particularly if you start extending methods from other packages. An issue I often run into at the same time as method ambiguity is a stack overflow from self-calling constructors. If you try to define an outer constructor with default arguments, it's really easy to end up just calling that constructor from itself.<p>The metaprogramming trick for defining a set of methods at once is useful, but I wish there were a more compiler-level solution to sorting out ambiguities or determining what's more "specialized".<p>These don't really color my view on multiple dispatch, however. I find it to be a really useful tool and I don't run into dispatch issues very frequently. If you're meticulous about your typing it's usually easy to avoid these pitfalls, but sometimes they still crop up.
method overloading is a horrible language feature that papers over the absence of other, more useful language features like optional arguments, etc.<p>i worked on a JVM programming language back in the day, and that damned feature screwed up <i>everything</i>: method resolution was obviously a pain, but it got involved in generics, class compatibility, it even ends up worming its way into bytecode, since methods <i>names</i> are really the <i>name</i> plus the fully qualified type name of every argument (even if there <i>isn't</i> any method overloading for a given method, just awful)<p>i wrote an old blog post on this:<p><a href="https://guidewiredevelopment.wordpress.com/2009/05/22/i-am-hate-method-overloading-and-so-can-you/" rel="nofollow">https://guidewiredevelopment.wordpress.com/2009/05/22/i-am-h...</a><p>in conclusion: things should have unique names