Re: [boost] [multimethods] Proposal: Open Multi-Methods

Subject: Re: [boost] [multimethods] Proposal: Open Multi-Methods
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2013-08-31 05:19:31

Hi,

For lack of interest, I will not go forward with the submission
process. I would like to thank the people who expressed interest and
provided suggestions and encouragements.

To those who will find this thread in the future: it does not mean
that the project is dead - or if it is, I hope that it is because open
multi-methods have finally made it into C++. Normally you should be
able to grab the library from GitHub (https://github.com/jll63/yomm11)
and read the documentation from http://www.yorel.be/mm/ A series of
articles (ongoing at the time of this post) provides a detailed
discussion of the library on Code Project
(http://tinyurl.com/m8kg2y3).

Regards,
Jean-Louis Leroy

On Sat, Jul 27, 2013 at 12:23 PM, Jean-Louis Leroy <jl_at_[hidden]> wrote:
> Hi,
>
> I am working on library that pretty much implements what Pirkelbauer,
> Solodkyy and Stroustrup describe in their paper "Open Multi-Methods for
> C++" - although there are some divergences. I have posted it on
> GitHub: https://github.com/jll63/multimethods. Please examine the
> files in the "examples" directory to get an idea of how to use it.
>
> Salient features are:
>
> * syntax: is relatively uncluttered. There are no limitations on the
>   number of virtual arguments. Virtual and non-virtual arguments can
>   be arbitrarily mixed. Multiple inheritance is supported, with some
>   limitations - see below.
>
> * speed: close to a virtual function call when the hierarchies
>   involved in the virtual arguments collaborate with the
>   library. Calling a method that does nothing, with a single virtual
>   argument in a single inheritance hierarchy is 33% slower than the
>   equivalent virtual function call. The difference becomes unnoticeable
>   if the functions perform a few simple maths operations. See
>   tests/benchmarks.cpp.
>
> * size: the dispatch table is constructed in terms of class
>   groups. This results, most of the time, in a table devoid of
>   redundancies. The size is bounded by the product of the number of
>   specializers - not classes - in each dimension.
>
> * support for "foreign" class hierarchies: the library can be used
>   without modifications to existing classes, at the cost of lower
>   performance. Collaborating and foreign arguments can be freely
>   mixed. Performance is still quite good, see the benchmarks.
>
> * next: a pointer to the next most specialized method is available
>   inside method specializations - see examples/next.cpp.
>   Alternatively, it is possible to call a specialization directly.
>
> Current limitations are:
>
> * restrictions on hierarchy: the classes involved in a method call
>   must have a single root. Repeated inheritance is not
>   supported. Multiple inheritance is supported, provided that the
>   two conditions above are respected.
>
> * no overloading: multi-methods are implemented as constexpr function
>   objects. This does not allow for overloading. This restriction can
>   be easily side-stepped by wrapping multi-methods with different
>   names in a set of overloaded functions. I know how to make
>   multi-methods functions instead of objects, at the cost of a
>   slightly less nice syntax for specializers. This is open to
>   discussion.
>
> Besides, the library differs from Stroustrup et al's
> paper on the following points:
>
> * a specializer specializes only one multi-method: what would "next"
>   mean otherwise? What would its static type be?
>
> * pure multi-methods are allowed: if called, an exception is
>   thrown. This seems a better choice given that most of the time the
>   declared virtual arguments will be abstract classes anyway.
>
> The library is essentially feature complete (if anything ever is). I am now
> going to
> work on the documentation, a build system, some clean up and compatibility
> (I tested it only with g++ 4.7.2 only so far).
>
> Is there interest in the Boost community for this stuff? If yes, I
> will adapt it to the guidelines and submit it for formal review. Of
> course, suggestions are welcome.
>
> Thank you for your time,
> Jean-Louis Leroy
>