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