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
