Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~
> On Wed, 19 Jan 2005 16:26:07 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> [ cc'ed p6l ] >> >> Matt Fowles wrote: >> > Leo~ >> > >> > On Wed, 19 Jan 2005 10:02:26 +0100, Leopold Toetsch <[EMAIL PROTECTED]> >> > wrote: >> > >> >>But where does that PerlMMD PMC come from? Does the Perl6 compiler >> >>generate one somewhere? >> >> > It is generated by the compiler. During compilation all of the >> > different MMD functions will necessarily be parsed and compiled, when >> > the first MMD function is compiled the compiler wil add a MMD PMC to >> > the appropriate table. Each time a specialized version is compiled it >> > will be added to the already created MMD PMC. >> >> Interesting. Where is this information coming from? Where can I read >> more about that? > The general idea that I am explain here has its root in the CLOS MMD > system. To define a set of MMD methods one calls (defgeneric foo (a b > c) ...) to add a particular implementation one calls (defmethod foo > ((Cat a) (Monkey b) c) ...). I smell some namespace pollution here. The namspace, where you ought to place the "generic foo" MMD PMC, could already contain a non-multi subroutine of that name. Second: S12 states that multi-dispatch can degenerate to single dispatch on plain methods, which seems to imply that the full MMD can't be handled by your proposed MMD PMC. > ... But the crux of my idea is the following > breakdown of responsibility Yep. That's the reason for splitting the functionality of find_method, which currently does it all. > The problem I see with that is calling a MMD function with arguments > from two different class systems. That'll be more fun, yes. But as long as the classes have a common ancestor, a matching MMD function could exist. > ... It would make more sense to me to > separate the dispatch system and the object system. Yes. But as C<dispatch> is (will be) a vtable you can always plug in the desired dispatch system in your metaclass. > Matt leo
