Re: RFC 97 (v1) prototype-based method overloading

>>>>> "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