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

On So, 2016-04-24 at 21:26 +0000, James Lin wrote:
Also, if we add signal::block()/unblock() then any object's signals
be blocked/unblocked even if you don't want to offer that ability.
breaks encapsulation, letting client code interfere with the
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.


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


Murray Cumming
murrayc murrayc com

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