Review of std.signal

[Martin Nowak]

On 01/06/2014 11:13 AM, Vladimir Panteleev wrote:
>
> 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 absolutely agree. Ideally the module std.signal would consists of a 
template struct with 3 overloaded methods.

struct Signal(Args...)
{
     void connect(void delegate(Args) dg);
     void connect(WeakDelegate!(Args) dg);

     void disconnect(void delegate(Args) dg);
     void disconnect(WeakDelegate!(Args) dg);

     void emit(Args);
}

Still, looking at the documentation 
(https://vhios.dyndns.org/dlang.org/web/phobos/std_signal.html) and 
implementation you're somewhat off.

Of course there are a few implementation issues.
- There is no WeakDelegate in druntime or phobos.

   Maybe requiring explicit disconnect is good enough?

- The lifetime of the delegate context could be scoped.

   No idea how to solve this one, but you could require that
   the delegate context is on the GC heap.

- When used this Signal definition requires boilerplate
   to restrict access to emit.

   This is unlucky but doesn't justify doubling the complexity
   of the module.

-Martin