Returning sigc::signal by value from a const method?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Returning sigc::signal by value from a const method?

Daniel Boles
I'm wondering about this for a project I'm writing. Would this be considered bad style? It's certainly possible (as signal is copyable, and many mm classes return it by value from non-const methods), but is it bad design for any reason?

My line of thought is that the signals only observe the object that emits them, so registering to be notified of changes is not modifying the emitter.

Letting a const instance return signals for observers to connect to would mean that I would not have to e.g. pass my model objects to my view objects by non-const reference, which I don't like the look of and can result in me having to cascade that non-constness all over the place.

Any thoughts welcome!


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Returning sigc::signal by value from a const method?

Daniel Boles
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Returning sigc::signal by value from a const method?

Murray Cumming-5
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
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Loading...