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
