> > It doesn't. The multimethod consists of those variants that are currently
> > loaded.
> >
> How do you define the currently loaded?
Accessible in the program's symbol table and registered with the multimethod
dispatcher.
> > > 2) If there is mismatch on more than one argument type,
> > > which argument should be favored more than the others.
> >
> > None of them. That's why Class::Multimethods doesn't use CLOS's awful
> > "left-most argument first" resolution mechanism.
> >
> So what is the next step. How do you define the next most-matched methods.
http://dev.perl.org/rfc/256.html#Finding_the_nearest_multimetho
> > That is simply not correct. There is a considerably body of research on
> > efficient dispatching. Dan is already aware of this.
> >
> I don't like this statement. If it was not an issue, why we need
> considerable research on it.
We don't *need* it, we *have* it. People did that research so that
efficient multiple dispatch would no longer *be* an issue.
> We can not put every superior solution into one language.
But we *can* put multiple dispatch in, since it greatly extends an existing
superior solution (single dispatch).
Damian
