> If one has a simple sub such as factorial:
>
> sub factorial(int $a) {...}
>
> then one subsequently declares the multi form of factorial to pick up the
> non-integer form:
>
> multi factorial(num $a) {...}
>
> Does this promote the original declaration of factorial to a multi?
> if not what happens?What happens is that the subroutine hides the multimethod (thoroughout the subroutine's package).
We didn't include it in A6 but our current notions (i.e. this week ;-) about interactions between subs, methods, and multimethods are something like this:
Dispatched to first existing
Call and visible of...
==================== ============================ foo($x, $y); 1. C<sub DISPATCH>
2. C<multi DISPATCH>
3. C<sub foo>
4. C<sub AUTOLOAD>
5. C<multi foo>
6. C<multi AUTOLOAD>
Invocant.foo($x, $y) 1. C<method Invocant::DISPATCH> or inherited 2. C<multi DISPATCH> 3. C<method Invocant::foo> or inherited 4. C<method Invocant::AUTOLOAD> or inherited 5. C<multi foo> 6. C<multi AUTOLOAD>
In practice, the C<DISPATCH> sub/method would rarely ever be used. It's just a hook by which to grab control of the dispatch process itself.
In the case of subroutines, there are three subcases for each subroutine dispatch. That is, if the table above says:
3. C<sub whatever>
that's really:
3a. Any in-scope C<my sub whatever>
3b. The current package's C<our sub whatever>
3c. The global C<sub *whatever>Damian
