On So, 2016-04-24 at 21:26 +0000, James Lin wrote: > > 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.
True. Though that's a bit like having a public virtual method, which lets outside code call the method directly. But signal::block() is a bit like making that virtual method do nothing if even the class itself tries to call it. A bit. > 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. I guess we should probably start doing that. We haven't had this problem with gtkmm because it actually gives people a SignalProxy which has a smaller API. > 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. It feels more like a fix than a major change of behaviour. Maybe we can fix that at least for now, so we feel better about getting rid of signal::slots(). Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org https://mail.gnome.org/mailman/listinfo/libsigc-list
