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