On Sat, Oct 14, 2006 at 07:56:24AM -0700, Jonathan Lang wrote:
: Right. That _almost_ takes care of the issue; the only part left
: untouched is what happens if you have two methods that can only be
: disambiguated by the invocant's role, and you aren't told what the
: role is. For instance:
:
: class DogTree does Dog does Tree {
: method bark( Dog: ) { ... }
: method bark( Tree: ) { ... }
: }
: my DogTree $x;
:
: $x.bark();
:
: In this example, what does the dispatcher do?
Never gets to the dispatcher if you write that, because you have to
write "multi method" in the class to share a short name like that.
The compiler's semantic analyzer will barf on such a name collision,
just as if you tried to redefine a sub. But we'll leave that aside
and take the "multi" as given.
If there's no good reason to choose one over the other, multi semantics
dictate that the most prudent course of action is to choose neither
and die of ambiguity. This is documented.
On the other hand, if you say one of:
$x.*bark();
$x.+bark();
then the dispatcher could arguably call them both. But we haven't
really talked about whether .* notation should extend to multi methods
within a single class. .* is intended primarily for calling one
method from each class, and if you take that view then the initial
call into the class succeeds but the redispatch into the class's
multi fails from ambiguity.
As usual, I can argue it both ways. Could probably even locate a
gripping hand or two if I tried a little harder...
Larry
