On Mon, Aug 24, 2009 at 12:42 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
I might be able to whip up an example if you want, but what it would do is populate a tree of type resolvers (this would actually allow for unlimited type resolution, not just two) with plenty of use of type_traits is_virtual_child and so forth all stuffed into templated structs that resolve the lookups. At compile time the tree is created, at call-time into the multimethod it creates a lookup in the tree that is specialized on the types passed into the multimethod caller, and at runtime the specialized caller resolves through the tree to compare the compile-time types at runtime, and if equal or if proper children, then it is equal and calls the necessary method, it will not fail since the base-most test could be tested at compile time as well and if it is not a child of that then it would fail at compile-time, but resolve to a specific function at runtime. I have been creating a lot of things like this recently for binding function between scripting languages and C++, makes things so easy once you figure out how to create it. I love Boost.Fusion. :)
It does sound fun, but I'm afraid I still don't understand how it changes the work required of the implementation to find the best method. I'm not sure if "call-time" is during compile-time or run-time. It sounds like the first, since you mention a "specialized caller". If so, that won't work because the static types of the parameters may not be the dynamic types. If the second, I don't see the advantage. Testing for proper children won't work in general, because a related type may not be a child. Besides, we don't need to check for that, because the method only accepts specific types. It is possible that a method implementation doesn't exist for that combination, but that can only be determined at run-time.
Just for note, if you do read the PDF, he describes a method that makes multi-methods have less cost then two virtual functions, and in many cases it has equal cost to one virtual function program-wide, so basically, much faster then your implementation, but his looks like it might require a compiler back-end change.
I was aware of the proposal for the addition of openmethods to C++. However, it's not even under consideration yet. I don't want to wait 20 years for multimethods to become a language feature. Furthermore if concepts are any example, when the time comes the multimethod proposal will do better if a library has already popularized them. Nick