Re: [boost] Boost.Multimethod proposal

Subject: Re: [boost] Boost.Multimethod proposal
From: Nicholas Howe (nicholas.howe_at_[hidden])
Date: 2009-08-24 21:00:51

On Mon, Aug 24, 2009 at 12:42 AM, OvermindDL1 <overminddl1_at_[hidden]> 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