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

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-05-13 22:33:21

Marco Costalba wrote:
> Giovanni Piero Deretta wrote:
> >  Marco Costalba wrote:
> >  >  Giovanni Piero Deretta wrote:
> >  >  > I think that in your case, using
> >  >  > operator= is confusing because you are not really reassigning the MSF but
> >  >  > just adding an overload. What if operator= tries to bind all signatures at
> >  >  > once (and thus allows for boost::function like adaptability) and operator+=
> >  >  > (or an explicit add member function) is strict and allows to replace a single
> >  >  > overload?
> >  >
> >  >  operator+= is a nice idea, like an explicit set() or add() method. I
> >  >  have been stick to operator=() just to follow boost::function API, but
> >  >  I agree in case of MSF this could be confusing...
> >  >
> >
> >  Well, in boost::function, operator= replaces the content of the
> >  function, which is
> >  not true in MSF case.
>
> In MSF it's true only for functions with same signature:

That's not the same thing. I think Giovanni was pointing out that
operator= normally replace all of the content of boost::function... or
anything else for that matter.

I think this is important. I like the idea of providing an assign()
for a sequence of callable objects implementing each signature.
However, operator= should retain its usual semantics of assigning the
Whole thingy on the lhs and not merely an element of the thingy when
the lhs is some sort of aggregate, which your multi-signature function
is.

<snip>
> >Operator+= might qualify as operator abuse, so
> >  an explicit
> >  set or add would be better  (but personally have no strong opinion on this)
> >
>
> Well set() is already implemented and it works also with the msf code
> you (probably) have downloaded. It is just that is not a documented
> API. This is because boost.function that used to have set(), has
> discouraged and then removed that API.

I think it would be better to replace set() with insert() (or if you
required the overload signature sequence to support random access, you
could do something like at()). Your function object is, in a way, a
collection of functions - an overload set - so it makes sense for it
to act like familiar containers. Actually, you could literally call it
boost::overload_set (after std::set and std::multiset) or with the
random access requirement you could call it boost::overload_vector
(after std::vector). You could call it boost::multifunction, but
following std::multimap, std::multiset, etc. that makes me think of
one signature mapped to multiple functions, which doesn't make sense.
Regardless, I would look for opportunities to merge the STL APIs
(concepts) for function objects and containers.

Daniel Walker