Re: [boost] [synapse] Review

Subject: Re: [boost] [synapse] Review
From: Peter Dimov (lists_at_[hidden])
Date: 2016-12-13 22:13:59

David Sankel wrote:

> No, there should only be one signal type and Boost.Signal made the correct 
> choice of using a so-called intrusive design.

I'm curious whether you can justify this opinion, because the answer is not 
as obvious to me. In fact, on its surface, the non-intrusive design is so 
much more flexible that one naturally tends to view it as the correct one.

For example, Boost.Signal works well for this design:

class window
{
private:
    // state

public:

    window( ... );
    ~window();
    // ...
};

We just need to add a few signals at //...:

    signal<void(...)> on_create;
    signal<void(...)> on_paint;

Synapse however works equally well with this:

class window;
window* create_window( ... );
void destroy_window( window* );
// ...

And with this:

class window
{
public:

    virtual ~window() = 0;
    // other abstract methods
};

window* create_window( ... );

And with this:

class window
{
private:

    class impl;
    impl * pimpl_;

public:

    window( ... );
    ~window();
    // ...
};

You could, of course, use Boost.Signals with all of those:

signal<void(...)>& on_window_create( window* );
signal<void(...)>& on_window_paint( window* );
// and so on

but with Synapse, all that boilerplate is unnecessary. (You still need to 
declare the signals, of course, but that's all.)

And, you can use Synapse even with this:

HWND CreateWindow( ... );
void DestroyWindow( HWND );

To get back to what you wrote,

> No, there should only be one signal type...

Except there isn't; but with Synapse, you can add a bit of scaffolding so 
that a library that uses its own signal type (or uses no signals at all but 
some other way of communicating, such as Windows messages or C callbacks) 
emits Synapse signals. Since you don't need to solve the problem of where to 
put the signal<> object, this is a relatively easy task.

Whether the Synapse approach is clearly better may be arguable; whether it's 
a legitimate alternative design isn't.