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
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