Mark A. Biggar mark-at-biggar.org |Perl 6| wrote:
To do multi method dispatch, you want to select the method that best matches the parameters in the call. One way to do that is to define a measure for distances between types and they use the method that's at the minimum distance. One simple measure is that a type is distance 0 from itself and distance 1 from it's immediate super-types, distance 2 from the immediate super-types of it's immediate super-types, etc. When dispatching over a single parameter picking the method at the minimum distance is the usual most specific type match. But when you want to do multi-method dispatch, you need some rule to combine the various distances of the individual parameters into a single measure value, then pick the method at the minimum distance by that combined measure. "Manhattan Distance" or "Taxicab Distance" is the rule that the combined distance is just the simple unweighted sum of the individual parameter distances. The is named after the fact that a taxi must follow the streets and to go 3 block north and 4 blocks west it must travel 7 blocks not the 5 blocks of the euclidean distance.
OK, so basically the fit is the sum of the fits of all the parameters. If form A has a distance of 2 for the first argument and 5 for the second, and form B has a distance of 0 for the first and 10 for the second, form A is better.
I heard this term come up the other day with respect to matching value types =and= other attributes such as rw or ref-ness. I thought he meant that these were different directions like streets and avenues, of one parameter.
I have problems with a simple sum. The "distance" is artificially inflated if you make lots of small derivation steps vs one large change. The concept of derivation steps is ill-defined for parameterized types and types that change virtual type names during derivation so there is no subtype relationship.
In C++, which must be resolved at compile time, the overloading resolution mechanism demands that =every= parameter be at least as good of a match, and one strictly better match. So the implementation never guesses if worse-left/better-right is a better fit than better-left/worse-right. However, you are assured that everything is brought to your attention at program build time, before run time, so complaining is not as serious as a run-time error where you might prefer DWIM.
--John
