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 _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org https://mail.gnome.org/mailman/listinfo/libsigc-list
