[multimethods] Proposal: Open Multi-Methods
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
On 7/27/2013 7:23 AM, Jean-Louis Leroy 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.
You need documentation. That is how you get others interested in a library.
I posted an article on Code Project that explains my views on OOP and why I think that open multi-methods are important. It is available here: http://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus1... Jean-Louis On Sun, Jul 28, 2013 at 1:23 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 7/27/2013 7:23 AM, Jean-Louis Leroy 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.
You need documentation. That is how you get others interested in a library.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Jean-Louis, Jean-Louis Leroy 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<https://github.com/jll63/multimethods>. Please examine the files in the "examples" directory to get an idea of how to use it.
I would be very interested in this library. As docs are still forthcoming, the original paper may be of interest to those that aren't familiar with multimethods: http://www.stroustrup.com/multimethods.pdf I'll check out the examples when I get some time. Thanks, Nate
Hi Nate - and Edward, I would like some feedback before starting the work on the doc because if there is a chance that this lib becomes a Boost library, I will write it directly in accordance with the Boost guidelines and traditions (i.e. imitate). I assumed that readers of this list will know what a multi-method is, in which case the examples show very clearly how to use the lib. The examples are by no means expected to replace proper documentation but at this point I just want to gauge the interest in a multi-method library done right (I think I that have achieved that) and perhaps spark a discussion on e.g. the exact names of the macros. I also avoided incorporating examples in my initial post to avoid clutter. What's the point of mixing English with code when the examples are but a click away? I preferred to describe the characteristics of my solution because there are many different approaches to implementing this kind of facility. Now maybe I am wrong on both points. Let's wait a couple of days and see... In the meantime I have added a step by step explanation of the "next" example, the most interesting and complete one, available here: https://github.com/jll63/multimethods/blob/master/examples/next.cpp Jean-Louis On Mon, Jul 29, 2013 at 6:49 PM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi Jean-Louis,
Jean-Louis Leroy 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<https://github.com/jll63/multimethods>. Please examine the files in the "examples" directory to get an idea of how to use it.
I would be very interested in this library. As docs are still forthcoming, the original paper may be of interest to those that aren't familiar with multimethods:
http://www.stroustrup.com/multimethods.pdf
I'll check out the examples when I get some time.
Thanks, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, Documentation for the library now exists and is available here: http://www.yorel.be/mm It has been pointed out to me I may be wrong in assuming that everyone knows about multi-methods. The introduction - http://www.yorel.be/mm/multi_methods/introduction.html - explains what they are and what they are good for. By all means, if you are interested, read the tutorial and look at the examples. Don't go straight to the reference. I believe that the library is more easily understood by looking at a complete example. It ain't complicated (from the outside), it just implements multi-methods. However, the macros, classes and templates listed in the reference don't make much sense taken in isolation. On the feature side, I lifted the restrictions on the inheritance graph that I mentioned in my original post. I also improved support for shared libraries and dynamic loading. Jean-Louis
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@yorel.be> 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
On 8/31/2013 5:19 AM, Jean-Louis Leroy wrote:
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).
The issue seems to be to justify practical use of multi-methods over traditional OO programming with virtual functions. Remember that the latter has been the core of OO programming for decades. I do not know even how to think about designing software using multi-methods as opposed to virtual functions. Without some serious practical benefits about the 'when' and 'why' multi-methods would ever be used in programming design it is hard to justify the idea, as clever as it seems to be. Perhaps it is an idea that has appeared before its time and it just needs some actual programming demonstrations which show its advantage before programmers become interested in it. Nonetheless I would like to thank you for bringing an implementation forth, even if its practicality eludes me.
On 08/31/2013 01:08 PM, Edward Diener wrote:
The issue seems to be to justify practical use of multi-methods over traditional OO programming with virtual functions. Remember that the latter has been the core of OO programming for decades. I do not know even how to think about designing software using multi-methods as opposed to virtual functions. Without some serious practical benefits
The example that Alexandrescu is using in his Modern C++ Design, chapter 11 on multimethods, is collision detection. Here you have objects of different shapes, such as rectangles and ellipses. Finding the overlap between two rectangles is different from finding the overlap between a rectangle and an ellipse. He also covers derived classes and symmetry (comparing rectangle-ellipse is the same as comparing ellipse-rectangle)
On 31-Aug-13 13:17, Bjorn Reese wrote:
On 08/31/2013 01:08 PM, Edward Diener wrote:
The issue seems to be to justify practical use of multi-methods over traditional OO programming with virtual functions. Remember that the latter has been the core of OO programming for decades. I do not know even how to think about designing software using multi-methods as opposed to virtual functions. Without some serious practical benefits
The example that Alexandrescu is using in his Modern C++ Design, chapter 11 on multimethods, is collision detection.
In the second article in my series on open multi-methods (to be published soon on Code Project), I examine another example: matrix addition. I also argue that open methods (multi or not, i.e. whether they have one virtual argument or several) are superior to virtual functions when it comes to modularity, extensibility and encapsulation. A friend told me that practical applications of multi-methods are common in adventure game programming, where constructs like "do this to that with something" abound. Languages like TADS support multi-methods for that purpose. See also my example (in my lib's docs) of a three argument method "approve(expense, role, reason)" in an expense approval system. Finally, multi-methods are not a recent idea. They have been around for 30 years and are available in many languages. Jean-Louis
On Sat, Aug 31, 2013 at 3:11 PM, Jean-Louis Leroy <jl@yorel.be> wrote:
A friend told me that practical applications of multi-methods are common in adventure game programming, where constructs like "do this to that with something" abound.
Indeed, and there are other cases of game mechanics where they are interesting. I'm interested in the subject but didn't have time to read the full documentation (either Stroustrup's document or yours), sorry. I read, some time ago, Stroustrup's document first page and thought it would be useful, but didn't read further yet. Joel Lamotte
participants (5)
-
Bjorn Reese -
Edward Diener -
Jean-Louis Leroy -
Klaim - Joël Lamotte -
Nathan Crookston