Review of std.signal

[Jacob Carlborg]

On 2014-01-06 11:13, Vladimir Panteleev wrote:

> Apologies, I missed this review thread. So, some questions / observations:
>
> IMO, the effort to disallow third parties to "emit" signals on your
> object by far exceeds its worth.
>
> For this purpose, you have needed:
> - string mixins
>    - ...which declare, by convention, a field with a name not explicitly
> given by the user
>    - ...with a workaround for when they don't work
> - an enumeration type
> - two different signal struct types
> - a boatload of documentation
> - a nontrivial cognitive effort on the user to grok all of the above
>
> This little feature steals too much focus, and IMO is not worth it.

I agree that it's not so nice looking. But I feel that it could be quite 
important to restrict emitting to the module the signal is declared in.

>> a.valueChanged.connect!"watch"(o);        // o.watch is the slot
>
> This is really ugly, but I don't see any way to improve it either. Maybe
> if the type of &classInstance.method was actually a special
> "pointer-to-class-method" type that implicitly down-casted to a
> delegate, it would be possible to safely use &o.watch instead...

I agree. Is the only reason to have a weak connection?


-- 
/Jacob Carlborg