Sam Ruby wrote:
Leopold Toetsch wrote:
A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc.
What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetical MMD PMC come from?
Since you are going to snip away everything, let's start all over.
First, a direct quote from <http://www.perl.com/pub/a/2004/04/16/a12.html?page=10>:
As we mentioned, multiple dispatch is enabled by agreement of both
caller and callee. From the caller's point of view, you invoke
multiple dispatch simply by calling with subroutine call syntax
instead of method call syntax. It's then up to the dispatcher to
figure out which of the arguments are invocants and which ones are
just options. (In the case where the innermost visible subroutine is
declared non-multi, this degenerates to the Perl 5 semantics of
subroutine calls.) This approach lets you refactor a simple
subroutine into a more nuanced set of subroutines without changing
how the subroutines are called at all. That makes this sort of
refactoring drop-dead simple. (Or at least as simple as refactoring
ever gets...)In the general case, a call to a subroutine with three arguments can have four possibilities: anywhere from zero to three arguments may be involved in the dispatch.
I also read this to say that whatever code is generated by a subroutine call is independent of the number of arguments involved in the dispatch. If you read this differently, perhaps we can get a ruling from the Per6 language folks. If I am correct, this will have the nice side benefit that any such methods can be invoked transparently by all languages.
None of this precludes a Polymorphic Inline Cache. Or Multidimensional Multimethod Dispatch. Or 30 to 70% performance improvements.
But it does constrain where the logic needs to be placed. And it does rule out syntax changes and using a different opcode for invoking MMD subroutines than non-MMD subroutines.
- Sam Ruby
