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

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.  

- James

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]