How would this differ from the signals/slots library? Robert Ramey Andrey Semashev wrote:

Nicholas Howe wrote:

...

I have written a C++ Multimethod library and propose adding it to Boost. I see that the addition of such a library to Boost has been proposed in the past, and been met with relative enthusiasm. However, it has not been done. Does anyone know why previous attempts were aborted? I want to be sure there is a demand before starting the somewhat daunting task of boostifying and documenting my library. The library works by requiring clients to register user types of interest, and specify their public base classes. This allows traversing class hierarchies at run-time. A multimethod uses this information to perform run-time overload resolution on registered methods to determine the best implementation based on the type-id of each parameter. There are no restrictions on the types of a multimethod's parameters, although only single indirections to user types will behave polymorphically. The library is designed to behave well when used by other libraries. To declare a new method, the client is required to derive a new type from the multimethod type. This allows multiple multimethods with the same parameters in different libraries. It also allows encapsulation of each multimethod implementation within each library, reducing the chance of conflict between different libraries that were compiled with different versions of the multimethod library. Is there any interest in including my library in Boost?

I'm definitely interested. What is the complexity of calling a multimethod? Is the code and some examples available somewhere? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, Aug 22, 2009 at 5:37 PM, Nicholas Howe<nicholas.howe@gmail.com> wrote:

On Sat, Aug 22, 2009 at 3:35 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

How would this differ from the signals/slots library?

The difference is that when invoked, a multimethod selects a single best registered method implementation based on the dynamic types of its parameters, whereas signal calls all of its registered methods, which accept parameters of the same type.

Hmm, interesting thought. What if all user-overloads where put in an mpl map, and you registered all overloadable functions in a similar way, but for the main function caller you could probably do something like variant does for its visitors and recursive down for each of the types based on the typeid (or more likely an mpl tag since it will be stuffed into an mpl map anyway) using fusion to resolve the type at runtime then using fusion::invoke or one of its kin, this would allow it to be very efficient and would remove basically all the indirection costs. Could be made even more simple and efficient if the user was willing to add a single macro into their class definition. Hmm...

Edward Diener wrote:

What is a practical use for multi-methods ?

Multimethods (assuming this library uses the term as it's commonly understood) are like virtual functions that are dispatched on the dynamic types of their arguments as well as the type of *this. You can get this effect through double dispatch, but it requires a bit of plumbing and requires two virtual calls (which for some people is a large amount of overhead). (Of course, multimethods have overhead too.) 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. --Jeffrey Bosboom

At 11:58 PM -0400 8/22/09, Edward Diener wrote:

This does not explain the practical purpose of multimethods. I know what virtual functions are, of course. What in multimethods improves on the polymorphic capabilities of virtual functions that make them a practical choice for use over normal polymorphism.

The previously referenced paper (http://research.att.com/~bs/multimethods.pdf) contains rationale discussion, including several well chosen examples where multiple dispatch can be beneficial.

Edward Diener wrote:

Jeffrey Bosboom wrote:

...

Edward Diener wrote:

...

What is a practical use for multi-methods ?

Multimethods (assuming this library uses the term as it's commonly understood) are like virtual functions that are dispatched on the dynamic types of their arguments as well as the type of *this. You can get this effect through double dispatch, but it requires a bit of plumbing and requires two virtual calls (which for some people is a large amount of overhead). (Of course, multimethods have overhead too.)

This does not explain the practical purpose of multimethods. I know what virtual functions are, of course. What in multimethods improves on the polymorphic capabilities of virtual functions that make them a practical choice for use over normal polymorphism.

Multimethods could be useful for various dynamic dispatch purposes. For instance, in Boost.Log I had to invent a similar mechanism to dispatch attribute values in other consuming components, like filters or formatters. Naturally, the attribute value types and types of filters and formatters are known only in run time. What I came up with was a double virtual call scheme, but that required quite an amount of scaffolding already. If I had to dispatch between three entities or more, this would get unbearable.

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