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

[James Lin <jameslin vmware com>]

Murray Cumming wrote:
> James Lin wrote:
> > So if you could add sigc::signal<>::block/unblock methods, then we
> > could stop using sigc::signal<>::slots (and have a better mechanism
> > to do what we want).
>
> Wouldn't it be best to just not emit signals that you don't want to
> emit?

Ideally, yes, but in practice I think it's easier said than done.  For example, suppose you have some object 
with a coarse-grained `changed` signal that is automatically emitted whenever a mutator on it is called.  But 
perhaps a client wants to mutate multiple properties on that object at once and does not want to trigger a 
flurry of unnecessary callbacks.  I think it'd be better for the client to temporarily block the signal than 
to:
A. Add arguments to every mutator to opt out of signal emission.
B. Add a non-emitting version of each mutator.
C. Add mutator methods that update different combinations of properties.

A signal also could be connected to another signal.  In that case, one could block the sigc::connection for 
the child signal, but keeping track of that is additional bookkeeping.

I suppose another alternative would be to create a separate class that wraps a specific type of sigc::signal, 
but that seems a bit awkward.

To some degree I also think that having sigc::signal::block/unblock methods would be nice for consistency 
with sigc::slot and sigc::connection.

- James