Re: [boost] [announce] Multi signature boost::function v1.0

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-05-14 12:05:38

On Wed, May 14, 2008 at 7:22 AM, Marco Costalba <mcostalba_at_[hidden]> wrote:
> On Wed, May 14, 2008 at 10:31 AM, Giovanni Piero Deretta
> <gpderetta_at_[hidden]> wrote:
>> On Wed, May 14, 2008 at 7:01 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>>  > AMDG
>>  >
>>  >
>>  >
>>  >  I suspect that there are really two tools here.  One which allows
>>  >  separate function objects to be bound to each signature, more like
>>  >  a fusion sequence or something.  The other binds all overloads to
>>  >  a single object.  Neither one is easily implementable in terms of the other.
>>  >  If all the signatures are bound at once, then it is difficult to later
>>  >  change
>>  >  just one.  If the functions are bound separately, then there is a
>>  >  significant
>>  >  size overhead compared to using a single object.
>>  >
>>
>>  Great point Steven.
>>
>>  Yes, my proposal would not let one rebind signatures separately (not easily
>>  at least). If this is an useful thing (really, I do not know), then
>>  please Marco, disregard most of my comments,
>>  probably I'm really looking for something else.
>>
>>  --
>
> Yes. I fully agree with Steven and with you. But because I have
> already implemented both features (indeed also a third one, see below
> for passing a boost::ref(poly_obj) ) I propose to do the following:

Not to be overly concerned with the aesthetic appeal of the function
object, but the fact that you already did the work is not a good
reason to include it in the library. That's not to say that your work
will go to waste, but that it shouldn't be exposed so directly to the
user. Sometimes what you leave out is as important as what you put in.
I would rather have a clean, orderly, even spartan interface than one
that supports ever imaginable feature. Here's a good saying: do one
thing well and then be extendable. If your function behaved more
container-like, or as Steve suggested, like a fusion sequence, then
each signature slot would hold its own callable object, but you could
do something like the following to bind all the signatures to a single
object as Giovanni requested.

overload_set<mpl::vector<int(int), float(float)> > functions;
fill(begin(functions), end(functions), ref(my_polymorphic_functor))

This is similar to what you are already doing with assign() or
set_all() or set_polymorphic_object(). I'm just saying that instead of
adding yet another member function, look for a more primitive,
fundamental interface. For example, add support for intrinsics like
begin() and end() that would let you do the same thing using external
algorithms as the member function would have done internally. If there
are efficiencies to be gained by having access to your internal
implementation, overload the algorithm (as a friend, for example) to
take advantage of your implementation. The point is the user has no
learning curve and your library becomes more flexible/generic; the
user employs your collection of functions interchangeably with other
collections of things and they all behave as expected. Your
multi-signature function is not merely an extension of
boost::function; it is a container of callable objects. Why not make
it act like one?! ;-)

Daniel Walker