On Wed, May 14, 2008 at 7:22 AM, Marco Costalba <mcostalba@gmail.com> wrote:
On Wed, May 14, 2008 at 10:31 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Wed, May 14, 2008 at 7:01 AM, Steven Watanabe <watanabesj@gmail.com> 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