On Sat, Aug 22, 2009 at 11:01 PM, Jeffrey Bosboom <jbosboom@uci.edu> wrote:
There's a Stroustrup et al paper on the feasibility of adding multimethods to C++ here: http://research.att.com/~bs/multimethods.pdf . I'm not sure how relevant it is to the current proposal, but it contains information on an experimental implementation that was faster than double dispatch.
In the terms of this paper, my proposal is for symmetric, open multimethods. My design principals differ in some respects from those of the paper. Mine are focused on a C++ multimethod implementation, whereas the paper's are on a C++ multimethod extension. As such, my principals are that multimethods should be non-invasive, extensible and support dynamic linking. I also prefer not to require a preprocessor. Multimethods should perform well, but in the case of double dispatch, it's unlikely that they will perform as well as the visitor pattern. However, because they are extensible, they solve problems the visitor pattern can't. My proposal is also for a design coherent with C++ call resolution semantics. Overload resolution to select the best multimethod is done at compile-time the same way as for any function. Ambiguity resolution is done at run-time. The dynamic type of each parameter is determined, and the method implementations are searched for the best matches. If there are multiple, equally-qualified matches or none, an exception is thrown. If not, the parameters are dynamic_cast to the types required by the method implementation. This can also throw. My proposal supports repeated and virtual inheritance. It does not support covariant return types. As for dynamic linking, my proposal supports the creation of multimethods using types defined by other libraries that are not aware of multimethods. It supports the addition of multimethod implementations to a multimethod in another library. I believe my proposal is functionally very similar to that of the paper. The paper defines a language extension that allows it to create multimethods that perform very well. I define a library that provides the same functionality, but not the same performance. Nick