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

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-27 01:30:08

> 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? 

Because some the chief arguments seems to be included in this
library being proposed.  The use of numbers after the signal
names was one of the key complaints cited when I proposed sigc++
to boost.  Obviously these arguments are dropped some place!?

> > 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.

Because as always stated, tracking of elements must run through the 
adaptors.  The signal code proposed does not address this as far
as I can tell.   If you construct a functor from a trackable element
using any of those other libraries you name, you lose the ablity to
track the object.  Any good signal/slot library will need to be
integrated with the binding of objects/methods and callbacks.  

Doing it any other way greatly increases the code bloat.  And 
worse overly complicates the code.
 

 
> 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. 

Growing each concept separately, often creates a large set of not
entirely integrated peices which in turn lead to horrible bloat and
inefficency.  

> 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. 

I think your goal is not exactly what should be that of boost.  Is it
the point of a standards orginization to simply hand down standards which
someone arbitarily feels is best or should it be adapted from those 
items which are found in industry to already work well?  I am not saying
fresh code is not needed, but you seem to really be reinventing the wheel.
Considering most of the interface (signals method name, connection 
concept) were taken from sigc++ why not adapt the whole thing rahter
than such peice meal.  
 
> Orthogonality in library design allows rapid innovation.

I don't see the other one as anything other than different implemention
without some of the major features.  Tracking of dependencies, ablity
to adapt while maintaining those and a slot concept which can be 
grown are all part of sigc++.  It seems a fairly orthagonal set.

 
> > 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.

Lack of adaptors.   SigC++ provides....

  auto_disconnect  - disconnect after a specific number of calls.
  bind             - place a value onto the last argument of a slot.
  bind_return      - give a return value to a void slot.
  chain            - call one slot with the return of another.
  hide             - add an used parameter to a slot.
  convert          - add intermedate function to a slot.
  slot (methods, object+method, function)
                   - create unified slot type to bind all those elements
                     with tracking.
  class_slot (object+method) - slot without tracking.
  closure (obj in slot+method)
                   - functor slot.

Providing this set with the boost::signal implementation or trying to
pull them in piecemeal will give poor results.  SigC++ draws rave
reviews from its users who frequently tell me it provides everything
they need so much so that when they discover "gee it would be nice to
have this" most I the time I point out it is already there.

The reason is you are implementing the same system which I went 
away from when I converted Tero's code.  That is requiring the
Signal to know something about the Slot.  

  signal.connect(functor()) 

implies that functor has operator()() of the type used by signal
and the signal gives it this info.

Now lets try to place an adaptor in the path...

  signal.connect(adaptor(functor());

adaptor must implement an operator()() for a connection type
which is not known.  Thus sigc++ is really more orthagonal as
the tools were meant to work together.

> > 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
> .

I considered dropping signal name myself, but as I have an actual slot
concept it makes sense.  Implementing signal by itself (without the slot)
just makes it too confusing.  It should be a function_list or something
like that.

The concept of signal/slot is simply any type of function/functor/method/
closure goes into a unified slot interface and that is what signal accepts.

--Karl