std.signals regressions

Robert jfanatiker at gmx.at
Sat Jul 13 13:37:45 PDT 2013


> But one comment though: Do you really need string mixins? I 
> think
> "Signal!int mysignal;" is a much nicer syntax in D than using

I agree and you don't need the string mixin, it is just for 
convenience. The signal itself is a struct. But what was 
important to me was that one can easily restrict emitting the 
signal to the containing class. This is where you need some kind 
of mixin to avoid boilerplate. But if you don't need that or want 
to write the boilerplate yourself you can just use the FullSignal 
struct directly.

I wanted to use template mixins because of the little less 
cluttered syntax, but as it turns out they are quite buggy, so I 
changed it to a string mixin with the added flexibility that you 
can select the protection of FullSignal, with private being the 
default. The syntax does not turn out to be that bad:

   mixin(signal!(string, int)("valueChanged"));

or if you want for example protected instead of private:

   mixin(signal!(string, int)("valueChanged", "protected"));

If you don't want to use the mixin and don't care that everyone 
can emit the signal:
   FullSignal!(string, int) valueChanged;


You see the mixin is just a feature, if you don't like it - don't 
use it :-)

> mixins /
> string mixins. And I think it's also quite important that a 
> signal
> implementation works with all of D's callable types - especially
> functions and delegates but opCall is nice as well.

It does work with all callable types: Delegates/functions and by 
means of delegates with any callable type.

Best regards,
Robert


More information about the Digitalmars-d mailing list