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

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2008-05-14 14:34:52

On Wed, May 14, 2008 at 5:05 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
>
> 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, I have to say that I agree with you 100% on the design goals
you present. In particular I'm a huge fan of keep it simple and do one
thing and do it well.

Also the argument of let MSF be orthogonal to standard algorithms is very sound.

What I'm asking myself is that if, in its current form, MSF can be
taught as a container. As example you wrote this

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

But begin(), end() and fill() need a forward iterator concept to work.
In it's current form, if I have to do the analogy with a container I
would say that MSF is more similar to an hash then, say, a vector or a
list.

It's a kind of hash with the key being a function signature: you throw
in a signature and get the underlying object. There is no concept of
order or position of an overload against another at least "in its
current form". I would need to throw in a good chunk of
metaprogramming infrastructure to get compile time constants for
indices and a bunch of metastuff to handle them. At the end probably
it would be another thing.

Also in the two examples that I wrote in documentation (a dynamic
dispatcher and an object factory) MSF is used as a value, as a
container item, of a std::map in the first case and of a tuple in the
second case. Also the examples of Govanni, for what I have understood,
treat MSF more has a value or a function object then a container.

Of course you are 100% right when you say that MSF could be a
container, but IMHO it depends a lot on the use. I explain myself
better. When dealing with MSF I tend to recognize two phases or two
steps (I'm not native speaker so please forgive me if I do not choose
the correct words).

First step is to load the gun: Define a MSF object and assign to it
the functions/functors

Second step is to shot: Use one or many of these MSF object to make
the job done (call stuff, dynamic dispatch, handle containers of MSF
items and so on)

I would say that I see more MSF as a container in the first step, and
as an item (of another container) in the second step.

Anyway this is very hand waving and probably fundamentally silly. So,
just to be concrete, I've pushed to boost Vault the file msf-1.1.zip
with the new stuff that arise from these very good discussions.

In particular there is the result_of support and the "controversial"
;-) set_polymorphic_object() code. I have updated tutorial.html and
test.cpp to reflect this.

One word regarding the API: it is EXPERIMENTAL. Reading this thread I
found a lot of good arguments to change the current function names,
unfortunately not all suggestion went in a single direction. So I more
or less left the API as it was, but I understand a lot of names,
starting from "multi-signature function" itself, are simple
placeholders for the future better ones as soon as we agree on what
they are :-)

Thanks for your precious feedback and help, response of all of you has
been overhelming, above my best expectations.

Thanks
Marco