Re: [sigc] Deprecate signal<>::slots() ?

[James Lin <jameslin vmware com>]

Murray Cumming wrote:
> Surely, if you can call m_signal.block(), m_signal.unblock(), and
> m_signal.emit(), then you can call the_signal_block(),
> the_signal_unblock() and the_signal_emit().
>
> the_signal_block()/unblock() just sets/unsets a bool and
> the_signal_emit() checks that bool before emitting the signal.

Yes, that's equivalent to what I meant about writing a wrapper class for specific types of sigc::signals.


> Even so, I think it's unwise to allow this from outside the class,
> because it's too low-level an API.
> [...]
> Also, if we add signal::block()/unblock() then any object's signals can
> be blocked/unblocked even if you don't want to offer that ability. That
> breaks encapsulation, letting client code interfere with the internal
> logic of the class.

That's also a fair point.  However, I contend that letting external code directly call sigc::signal::emit(), 
emit_reverse(), and particularly clear() also breaks encapsulation.  There's already an assumption that 
clients won't abuse the sigc::signal and that anything that cares about encapsulation should wrap a private a 
signal and expose only a connect() method.

Anyway, I wasn't aware that sigc::signal_base already provided block/unblock methods. (Looks like it was 
introduced in 2.3.x.) That's unfortunate since it means that I'm now asking to change existing behavior.  
Drat.

- James