Re: [boost] SUBMISSION: Signal/slot library

From: Tomasz Kowalczyk (tomek_at_[hidden])
Date: 2000-04-05 09:45:58

"Borgerding, Mark A." wrote:
> 
> Sorry, I don't have many comments on the code itself, mainly on the concepts
> and presentation.
> 
> Let me start off by showing my ignorance.  I am not really familiar with the
> concept of signal and slot.
> 
> I found the Qt documentation about it and it sheds a little more light.
> http://doc.trolltech.com/signalsandslots.html

If you need explanation of the concepts, you should have a look in
http://libsigc.sourceforge.net. It is a similar library for Gtk-- (Gtk+
wrapper in C++). They use more modern C++ and have nice narrative
explanations on their site. They have done a pretty good work and
libsigc was my main inspiration. 

I left that references on purpose. They restrict you to think in terms
of GUI and GUI notifications. In my opinion a proper way of thinking
about this mechanism is about storing arbitrary code for later
execution.

> 
> It would help clarify your explanation if you noted the strengths and
> inadequacies of the Qt approach (like the fact that it seems to need a
> special compiler is a *major* drawback). And then comment on how your
> approach builds on the strengths and addresses the inadequacies.
> 
> I have a hard time thinking up some good examples.  Some code and narrative
> explanation might help to clarify.

Hmmm.. There is not really that complicated to require long
explanations. But if you want an example, here is what a typical usage
in a GUI program may look like.

Here we have two completely unrelated classes: Button - written by a GUI
wizard, and Greeting - fruit of work of skilled young hacker believing
only in CLI. Nevertheless we want to make them talk to each other.
Normally it would not be easy, but we are lucky, because GUI wizard was
using a signal library:

struct Button {
        ...
        signal<int,int> pressed;
};

struct Greeting {
        ...
        void say_hello() { cout << "Hello !" << endl; }
};

int main() 
{
        Application app;
        
        // Create a window and two buttons.
        Window *my_window = toolkit::make_window("Hello window");
        Button *button = toolkit::make_button( "Press me" );
        Button *quit = toolkit::make_button( "Quit" );

        // Welcome message
        Greeting welcome;

        // Remember how to call welcome.say_hello() in button's
        // "pressed" signal
        button->pressed.connect( closure( &welcome, &welcome.say_hello ) );

        // Remember how to call exit() in quit's "pressed" signal
        quit->pressed.connect( function(&exit) );

        // Add buttons to the window and show everything
        my_window->add( button );
        my_window->add( quit );
        my_window->show();

        // Run the event loop
        application.run();

        // Now if the user presses "Press me" button, then a message
        // "Hello" is printed to the terminal.
        // If the user presses "Quit", program terminates.
        
        return 0;
}

> 
> It may just be my unfamiliarity with signals and slots, but I question
> whether something that is based on callbacks is the right idiom to promote
> for C++.

You use callbacks each time you call std::for_each

> 
> By the way, I think that (Qt's) choice of the term "signal" was a poor one.

I do not agree and I do agree. In the context of a Widget toolkit a
signal/slot abstraction quite accurately expresses the idea of something
happening + transmition of associated data + absorbtion of that data.
Moreover, this very abstraction was very likely the main reason for Gtk
and Qt to become the most popular toolkits nowadays. It has been quite
common that each new toolkit introduces its own terminology for
notifications. They can usually be described in terms of a noun + verb +
noun. Thus we have had event + fire + handler, message + send +
receiver, why not signal + emit + slot ?

I do agree however, that an abstraction like this effectively prevents
you from taking a little more wider view, and this is a bad thing.

What would be your choice for the name ?

> 
> - Mark
>