Re: [boost] libsigc++ inclusion (was Formal review request: Signals library)

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-12-27 00:50:10

On Wednesday 26 December 2001 08:21 pm, you wrote:
> I have suggested libsigc++ in the past as a boost component, but
> the reasons given for not including it were fairly strong, only
> now it appears those reasons have vanished and a new set of design
> arguments have appeared. 

What reasons have vanished? 

> Why was it when I first proposed signal/slot
> implemention boost didn't need such functionality as it was too blended
> with functor, but once function and bind (horrible, horrible name!!)
> which others said were all that are needed, does the signal/slot
> seems appropraite?

I don't believe anyone ever said that such functionality wasn't needed.
At that time, Boost really needed a callback class (e.g., for the threads 
library), and it was thought that signals & slots were a much higher-level 
concept that could be implemented well on top of a callback. Perhaps we would 
even get some new insight into signals & slots by considering at length the 
more basic callback concept.

See http://groups.yahoo.com/group/boost/message/6569

> That said there are significant hurtles to ever including sigc++.
>   1) SigC++ uses a totally different naming convention.
>   2) SigC++ maintains itself with autoconf and similar tools.

These aren't really hurtles; they're both straightforward (albeit dull and 
unrewarding) changes.

>   3) SigC++ has some sections which are redundant to reviewed boost
>      components, though they were not necessarily such when sigc++
>      was written and proposed.

This, for me, is the main reason I believe that SigC++ does not belong in 
Boost. Why should a signals & slots library contain code for binding 
arguments in calls to member functions? Why should it contain adaptors to 
perform type conversions on slot call arguments when the types don't match 
exactly? There are libraries that do this type of operation - Bind, Lambda, 
FACT!, FC++, Spirit semantic actions, etc. - and do it better than we can 
expect a signals & slots library to do it, because a signals & slots library 
isn't about argument binding or function composition at all.

I'm wondering if the not-invented-here stigma is because Boost is designed 
differently from most libraries. SigC++ presents a full signals & slots 
system, and is a great standalone system for its users. The entirely of Boost 
is meant to be a standalone system, but it's libraries need not be (and 
high-level libraries shouldn't be) High-level concepts are built on low-level 
primitives, but Boost libraries don't tie themselves to a specific low-level 
implementation but instead to a concept specification. The Boost.Graph 
algorithms are written irrespective of the underlying graph representation, 
just like STL algorithms are written irrespective of the underlying 
containers or sequences; we don't see special forms of std::for_each or 
std::find_if that deal with member functions, or std::sort for a deque, and 
we don't see boost::isomorphism specialized for a boost::adjacency_list. 

Let say both SigC++ and the Signals library are accepted in their current 
states. Now a few months down the road Boost accepts the Lambda library - the 
Signals library is automatically more powerful, because now slots can be 
created in a more natural way with Lambda; how quickly will SigC++ adapt? 
Does Lambda get pulled into part of SigC++? Are the internals of the Lambda 
Library changed to fit SigC++? Does the older, non-Lambda binding interface 
still exist? For how long? Should it be standardized along with the Lambda 
interface? Such questions need not be answered if signals & slots were 
decoupled from binding: the committee chooses the best binding library of all 
of the choices, and chooses the best signals & slots library of all of the 
choices. 

Orthogonality in library design allows rapid innovation.

>   4) After inclusion in boost, SigC++ will live on as an LGPL component
>      until such time at it makes the stl standard.  Which
>      means contributions to it will not necessarily go back to boost
>      if done by someone other than myself.

This may be a maintenance nightmare, but it's not the first time this has 
come up. Loki would have the same problem, and I'm sure we'd find a way to 
deal with it.

> That said, if boost accepts the current set of functor/bind/signal
> combination, and then tries to place it in the stl standard, I
> feel they will be doing a bit of a disservice as some of those
> elements are handled much more gracefully in sigc++.   

Please give examples.

> Thus at
> least if sigc++ isn't included a serious discission of the features
> that sigc++ offers and doesn't should be seen here again prior
> to accepting any signal/slot library.

A serious discussion of what sigc++ offers would be very beneficial for all 
of us. I've read the documentation and skimmed the source code, but I'm sure 
there is much I've missed.

> BTW.  If you are going to drop the slot side of the equation,
> you should really drop the signal name.  Signal/Slot is a unified
> concept and thus if there is no slot class but functors are used,
> don't use the signal name.  It is so badly overloaded between
> Unix system calls, including a class "signal" would really be asking
> for pain in the long run.

Suggestions always welcome. Signals & slots seems to be the "popular" adopted 
name, and thus I chose to keep it even though slots are not concrete entities.

        Doug