On Sep 28, 2004, at 9:13 AM, Danil Shopyrin wrote:
Background. My solution is an "idealized" solution. It is stands as an answer to question: "can multimethods be implemented in C++ using only 'good' programming techniques?" It is fully compile time and absolutely type safe. And there is no of RTTI. This is an academic result. Moreover, this is ready to practical use (I do it).
Well, what is ideal is in the eye of the beholder and many people seem to approach multimethods from a rather pinched perspective. Many developers seem to take them at face value and consider them as a tool for handling those rare (but annoying) cases where you need to dispatch on multiple types. Things like intersection or collision tests. I think of them differently: as a complement to the dynamic dispatch performed by virtual functions. The difference is that multimethods allow dynamic methods to be added without disturbing the class which is invaluable if you can't edit the class or don't want to load it up with methods that are used in only a few places in the code. Secondarily, they also allow dispatch using multiple types which opens up the possibility for non-traditional solutions to icky things like event dispatching in GUI frameworks.
Further, about drawbacks:
1) Compile time. Yes, this solution is strongly compile time. But I think it is an advantage :-)
I disagree. The biggest benefit of multimethods is that they are flexible. If you wire in all the methods at compile time you lose a great deal of that flexibility. In particular frameworks can't provide customizable multimethods to clients: designers are either forced to abandon multimethods or require users to wire them up even if most of the behavior is stuff that should be defined in the framework.
2) You are right. There is no "next_method". I was never think of them.
Well, they aren't needed for simple use cases. But they seem quite valuable in more complex scenarios.
3) Intrusive. It is eliminated.
It still requires user classes to be designed with multimethods in mind though. Each class that is dispatched upon needs a visit method which is a pretty annoying restriction.
4) "distinguishes the first argument". It is eliminated.
Good. :)
5) Gnarly user code. Look at up-to-date "tiny use case" at http://sdanil.narod.ru/mm/m2vd3_v5.zip
Which file are you talking about? -- Jesse