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