Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >>>>> "EH" == Evan Howarth <[EMAIL PROTECTED]> writes:
>
> EH> Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >> Why would anyone want to select a different method based upon the
> >> arguments.
>
> EH> The classic example is event dispatch. Say a generic event
> EH> handler knows how to handle an event base class. It dispatches
> EH> handling to some class that registered interest in the events.
> EH> Somewhere the code has to select the right event handler per
> EH> event type. Having "multimethod" support simplifies such code:
> EH> It reduces to method declarations. Without it, each registered
> EH> class needs to include the code to determine which event
> EH> occurred and where its handler is found.
>
> Sounds like action at a distance. And this would be done at
> compile time (for a language like C++), no?
You keep using that phrase, I don't think it means what you think it
does. It all hangs on what you mean by 'distance'. From the OO point
of view, having class dependent behaviours expressed outside the class
could be viewed as action at a distance in this context.
But this probably isn't the right place for this discussion.
> EH> perl6-language-flow. An IO exception contains different data
> EH> and is handled differently than a out-of-memory exception.
> EH> Without multimethod support, the flow people are arguing
> EH> syntax and ways to distinguish among the many exception types
> EH> so that the correct handler code is invoked.
>
> That still doesn't seem to by why I should hide it in the signature.
Why does your catch code need to know any more than: "This is an
exception object and I just call its handle method with a couple of
arguments and let the dispatch system handle it from there"?
--
Piers
