[boost] Boost.Python def and member function overloads

Subject: [boost] Boost.Python def and member function overloads
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-05-05 00:54:27

I attended Troy Straszheim's Icefishing for Neutrinos Boostcon session
today, which was a great talk on Boost.Serialization and Boost.Python in
a very interesting context. I have not worked with Boost.Python in practice,
having only skimmed the documentation, but was amazed at just how powerful
and easy to use it is.

However, in his examples, he included exposing classes from C++ that have
member functions with multiple overloads and noted that it is somewhat
cumbersome due to the fact that you have to explicitly cast your member
function pointers when calling .def. For a type "your_type" with a member
function "foo" having two overloads, one that takes an int, and another that
takes an int and a float, the current syntax comes down to something along
the lines of:

/*class_ specification here */
.def( "foo", static_cast< void (your_type::*)(int) >(&your_type::foo))
.def( "foo", static_cast< void (your_type::*)(int, float)
>(&your_type::foo))
;

Disambiguation is obviously necessary here, but I wonder if it could be
handled in a much simpler way such as to avoid explicitly casting or even
the explicit use of member function pointer types at all. I propose doing
this by allowing users to explicitly pass in a non-member function type as a
template argument to def, using a metafunction to translate that type
to the appropriate member function type, and having that calculated type be
the 2nd parameter type of the function. The suggested syntax would be
something along the lines of:

/*class_ specification here */
.def< void(int) >( "foo", &your_type::foo )
.def< void(int,float) >( "foo", &your_type::foo )
;

which I feel would be a significant simplification of use and should not be
difficult at all to implement (just detect if the first template argument to
def
is a function type and if so do the appropriate transformation to
yield the 2nd function
parameter type, otherwise have it work like existing definitions). Would
this be a feature that people find useful and be worth pursuing?

-- 
-Matt Calabrese