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

[Murray Cumming <murrayc murrayc com>]

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
murrayc murrayc com
www.murrayc.com