> Because multimethods are inherently an OO technique.
>
You can say so, but I am not buying it very much.
> It doesn't. The multimethod consists of those variants that are currently
> loaded.
>
How do you define the currently loaded? If things are lazy loaded, the stuff
you expect has been loaded
may not have been loaded.
> > 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.
> 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.
> Multimethods elegantly solve a very hard problem in OO design: controlling
> the interactions of multiple objects fom multiple class hierarchies.
> They are not required often, but when they are needed (e.g. in the
> Quantum::Superpositions module), they are a *vastly* superior solution.
>
We can not put every superior solution into one language. If we do, we don't
even need Perl 6, since all
solutions are included, there is no need to write program. It is just like
Fortran has built-in math functions,
but C does not. With optimized C compiler, we can achieve similar performace
with obviously more code.
Let's say C is only 80% of Fortran on math, I still don't see the reason to
put math into C language for
the last 20% of speed. It may be my personal preference. I am not going to
argue on this any more.
Hong
