On Tue, Mar 11, 2003 at 06:08:59PM -0800, Michael Lazzaro wrote: : : 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().
No, a sub declaration must continue to be a strong claim that it is the only implementation *in scope*. : 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). It would silently not work in exactly the same sense that any other sub that is out of scope is invisible. : 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. There's no reason you can't write a multi that calls the sub. That multi would be visible anywhere the sub wasn't. Larry
