Hong wrote:
> > Note that the handler that is selected depends on the *combination* of
> > the types of the two arguments. And that the dispatcher understands
> > the argument/parameter inheritance relationships and selects the most
> > specific handler for each combination. For example, a MoveEvent sent to
> > a FixedWindow causes a beep, but a MoveEvent sent to any other type of
> > window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
> > subroutine, which causes it to move.
>
> I believe this feature has some conflict with OO dispatch. In a pure
> static procedure language, this can be nicely and easily done. I am not
> if we really this for Perl.
We already have it in Perl (in the Class::Multimethods module). There's
no conflict with regular OO dispatch. In fact the two work quite well
together. Because multimethods are inherently an OO technique.
> 1) How do we find the method if the package is lazy loaded? The "sub"
> can sit in some package that is irrelavent to the argument types. How
> can runtime decide whether to use handle(Window $w, Event $e) or try
> to load some 'magik' package, which happens to define
> handle(Window $w, FooEvent $e).
It doesn't. The multimethod consists of those variants that are currently
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.
> 3) The multi dispatch is generally slow and complicated.
That is simply not correct. There is a considerably body of research on
efficient dispatching. Dan is already aware of this.
> Since it does not fit well with OO concept
That is simply not correct. Multiple dispatch is fundamentally *only* an OO
concept. It is a generalization of the fundamental OO concept of single
dispatch.
> it will just cause more confusion.
This *might* be correct but, since multimethods will be optional, it probably
won't matter. ;-)
> Typically we use different solution for OO language vs procedure
> language.
...one that is slower, uglier, and more error-prone. :-(
Multimethods elegantly solve a very hard problem in OO design: controlling
the interactions of multiple objects from 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.
Damian
