On Sat, 2017-07-22 at 10:58 +0100, Daniel Boles wrote: > As an aside, since realising that providing any form of full access > to a signal gives external users the ability to emit() it, clear() > it, etc. - I am considering moving to a model whereby I only expose > signals via a method like this: > > sigc::connection signal_whatever_connect(signal_whatever_type slot); > > This involves quite a bit of boilerplate, albeit not all that much > worse than what we have to write to implement a (pointless) by- > reference or -value getter anyway. > > > However, it got me wondering. Has anyone ever come up with a better > way to only allow users to connect() to signals and nothing more, or > at least a way to reduce the required boilerplate of my proposed > mechanism somehow? > > I did find an old thread where IIRC Murray talked about how he would > like to see access control on signals, FWIW! That may have changed in > the meantime, whether through opinion or just practicality. > > I guess it could be done, but with smoe huge API changes; e.g. I > imagine we could return a base class that does not have the modifying > methods from our own objects, while using a derived class that does > provide them internally. > > > At the end of the day, the real question is whether the work of > providing access control would be justifiably better than just > requiring users to encapsulate signals for themselves; I suspect the > answer might be no. Still interested in any thoughts.
I'm not aware of any efforts to make this easier. It does bother me too. -- Murray Cumming [email protected] www.murrayc.com _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
