> For example, here is an event handler for a GUI:
>
> sub handle (Window $w, Event $e) : multi {
> log("Unknown event $($e->desc) called on window
$($w->name)");
> }
>
> sub handle (Window $w, CloseEvent $e) : multi {
> $w->close;
> }
>
> sub handle (ImportantWindow $w, CloseEvent $e) : multi {
> $w->close if yesno_dialog("Really close this window???");
> }
>
> sub handle (Window $w, MoveEvent $e) : multi {
> $w->moveto($e->newpos);
> }
>
> sub handle (FixedWindow $w, MoveEvent $e) : multi {
> beep();
> }
>
> 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.
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).
2) If there is mismatch on more than one argument type, which argument
should be favored more than the others.
3) The multi dispatch is generally slow and complicated. Since it does
not fit well with OO concept, it will just cause more confusion. Typically
we use different solution for OO language vs procedure language.
Considering X/Motif/Gnome, you always register handler for specific event.
The event dispatcher just search the event map. So you can use the same
event handler for different window types and different event types.
Hong
