>>>>> "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?
EH> Another example is the exception catching being discussed on
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.
EH> Although not as common a need as polymorphism, multimethod
EH> support would be useful.
I'll wait and see.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
