53591 gabor I have many examples from my day job. (Optical Crossconnect Business, Alcatel-Lucent, probably sounds familiar :-) Here is one where multi-methods would be ideal: (I am using the dylan syntax for the sketch) //----------------------------- define class <synchronous>(<object>) end; /* define class <plesio>(<object>) end; ... other transmission methodologies */ define class <tributary>(<object>) slot matrix-ref :: <integer>; end; define class <wrapped-ethernet>(<tributary>) end; define class <synchronous-tributary>(<tributary>, <synchronous>) end; define class <SDH-tributary>(<synchronous-tributary>) end; define class <SONET-tributary>(<synchronous-tributary>) end; define generic crossconnect(from :: <tributary>, to :: <tributary>) => (); // (1) define method crossconnect(from :: <tributary>, to :: <tributary>) => (); matrix-connect(from.matrix-ref, to.matrix-ref); end; // (2) define method crossconnect(from :: <synchronous-tributary>, to :: <tributary>) => (); next-method(); enable-external-fault-monitor(from); end; // (3) define method crossconnect(from :: <synchronous-tributary>, to :: <wrapped-ethernet>) => (); next-method(); enable-extra-bandwidth(to); end; //----------------------------- In our system we have a dozen of transmission types, so the combination of input->output becomes huge. Currently all processing is done in various huge functions with many "if" clauses that check for the various specializations. It is a mess. Using multi-methods would be a big leap in maintainability. What I have shown above is the binary dispatch case, but usually there are some more arguments which also guide the behaviour and are best included in the dispatch scheme. Dispatching over 3-4 arguments is not uncommon, and such a situation would definitely break any visitor-like pattern. The only thing one has to be careful with is the ambiguity of the method resolution (Dylan resolves in a symmetric way (for arguments) but respects the left-to-right order of class inheritance (when multiply-inherited).) A good compiler warns the user if ambiguities can lead to surprising method selection. Another nice example to multimethods is when a state machine is triggered in different situations. For example a circuit can be completed by the local segment or by a remote segment, and whether this segment is the dropping segment of the circuit: //----------------------------- define generic completed-by (state :: <state>, situation :: <segment>); //----------------------------- here we typically have 6-8 states and 8 situations ({local, remote} x {add, thru-out, thru-in, drop}). 3408458017 #dylan None