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

[Murray Cumming <murrayc murrayc com>]

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
murrayc murrayc com
www.murrayc.com