On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
You want C<multi> to tell the compiler to build in multiple dispatch. Any invocation of C<foo> after C<multi foo> is going to be a penny dropped into the great Pachinko game of multimethod-dispatchery. By default, if no winning multi appears, the call falls out the bottom and winds up invoking the original sub().
OK, hmm. What Damian is saying is that, tentatively, it's the reverse... it calls the sub if theres a sub, then the multi if there's a multi. So overriding a sub with a multi wouldn't work, but it would *silently* not work, because you could just never get to the multi version (well, not without a bit of introspection).
I agree that the issue of overriding an inherited/preexisting C<sub> -- like one from a CPAN module -- with a set of C<multi> implementations is a useful capability; it would allow you to extend predefined routines to handle different arguments without getting into OO. But I sure worry that it makes accidental redefinition of subs invisible in many cases.
Dunno. I could argue that one both ways. Maybe it has to wait until A12.
sub foo($a) {...}
... lots of code inbetween ...
multi foo(int $a) {...} # (???) multi foo(str $a) {...}
MikeL
