Re: [boost] Boost.Multimethod proposal

Subject: Re: [boost] Boost.Multimethod proposal
From: Nicholas Howe (nicholas.howe_at_[hidden])
Date: 2009-08-29 09:02:24

On Sat, Aug 22, 2009 at 11:01 PM, Jeffrey Bosboom <jbosboom_at_[hidden]> 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