Review of std.signal
Robert
jfanatiker at gmx.at
Tue Nov 12 07:39:21 PST 2013
> Robert, for someone who has only vague knowledge of signal
> stuff (me), can you explain why exactly this design was
> necessary? (mixing in global variable and wrapper function
> which returns its restricted version) Is the desire to separate
> protection attributes the only motivation or there are some
> other concerns?
No this is the only reason. Usually it is the common case that
you only want the "owner" of the signal to emit it. Without the
mixin, this would require the following boilerplate for every
single signal:
ref RestrictedSignal!(SomeTemplate!int) mysig() { return
_mysig;}
private Signal!(SomeTemplate!int) _mysig;
which is a bit tedious.
I am currently considering the suggestions of Jacob Carlborg:
- using an enum for the protections
- provide an additional template mixin wrapper for another minor
reduction of boilerplate.
Signal slot frameworks in C++ usually either only allow the owner
to emit the signal (Qt) or you are required to write some wrapper
functions for restrictions on the public API (e.g. boost signal).
Best regards,
Robert
More information about the Digitalmars-d
mailing list