Re: [boost] SUBMISSION: Signal/slot library

From: Tomasz Kowalczyk (tomek_at_[hidden])
Date: 2000-04-07 22:11:04

Joseph Davis wrote:
> 
> I have been using the Qt Signal/Slot mechanism for about a year, and I find it to
> be a practical idiom.  I have not used the libsigc version (we use Qt), but I did
> explore the links mentioned in this thread.  Reading this also makes me wonder
> whether or not the proposed submission would fill a roll in the boost library.  If
> the code is better, more portable, more "open", it certainly might.

This is exactly what I wanted to hear. Now my questions are:

What needs to be made better ?
What part do you think is not portable ?
What aspects should be more "open" ?

> 
> My reason for replying is that there continues to be something about this idiom
> that troubles me, although I haven't really put my finger on it.  The GoF Design
> Patterns book discuss at least 3 related design patterns that relate to this
> topic.  OBSERVER (293) is used to define a 1 to many dependency between subjects
> and observers, so that when a subject changes state, all its dependents are
> notified.
> 
> MEDIATOR (273) encapsulates how a set of objects interact, promoting loose
> coupling.  My first realization of how neat STL is came by implementing a basic
> MEDIATOR between subjects and observers using a multimap.  The main line of code is
> 
>   std::multimap<ISR_subject*, ISR_observer*> m_actionMap;
> 
> where ISR_subject and _observer are abstract base class for those types of
> objects.  The implementation of the entire mediator class is about 70 lines of
> code.
> 
> Most applications would probably build their central MEDIATOR as a SINGLETON (127)
> so that attaching and detaching actors would be easier.  However, should the need
> arise for different types of mediators specialized for various purposes, that could
> be easily done as well.
> 
> In this approach, the mediator passes a pointer to the subject that changed to each
> interested observer.  The observer can then query the subject for data as
> appropriate.  Obviously, any changes in the data interface functions to concrete
> subjects, will force rework on all concrete observers.  Such is life.
> 
> It seems to me that signal/slot addresses these same issues and probably uses much
> the same design architecture.  However, client code tends to be vectored away from
> the MEDIATOR implementation.   It seems to work well if the relationship between
> the object that emits the signal and the object that hold the slot can be neatly
> handled by relatively simple data like that between GUI primitives like buttons and
> edit boxes.
> 
> In other words, signal/slot may not really be appropriate if the object with the
> slot really does need to observe changes in state of a complex object.  I suspect
> that if lots of signals need to be coupled to lots of slots, then the design of the
> MEDIATOR in the middle will become the focus of much optimization worries in
> complex apps.
> 

As far as I know, Qt uses some central mechanism for event dispatching.
Decentralization usually gives you code which scales better, and with
some tradeoffs you can avoid the central mediator if you can use member
function templates and class template specialization. The tradeoffs are
related to possible problems with linking.

> I also worry about complex interdependencies causing cascades of unnecessary
> updates.   The solution if you write your own MEDIATOR is to write a better
> MEDIATOR.

I did. I have no MEDIATOR at all :)

> 
> Sorry for the long winded reply.  I suppose my main worry is that overuse of
> signal/slot could lead to big troubles with medium to large designs.  It seems fine
> for certain rolls, like wiring GUI elements into your app.
>