* If a template mixin, which uses the string mixin, is provided
the syntax will look a bit nicer
It does, as it saves two to four brackets for multi arg signals,
I nevertheless decided against it for the following reasons:
1. Despite being a little more verbose, I like its style better.
Maybe because the name of the signal is separate from its
parameter types, providing a bit more structure.
2. Naming problem. The template would have to start with a
capital letter according to the D style rules, thus it would
clash with the struct Signal. I could name it Sig or something or
rename the struct. A stupid reason, but it troubles me a bit.
3. It is just another level of indirection making it arguably
harder to understand what is going on: template mixin -> string
mixin -> struct.
* Isn't it better to use an enum for the protection attributes?
Having put some thought into this, while it seems to be, I think
it isn't.
Enums in D are scoped, so for the enum:
enum Protection { protected_, private_, none }
The syntax gets more verbose instead of less:
mixin(signal!(string, int)("valueChanged",
Protection.protected_));
instead of:
mixin(signal!(string, int)("valueChanged", "protected"));
Also you can use the keyword as is and as every programmer is
used to. Pro enum would be tool support (auto completion) but I
suppose people would almost always use the default anyway and if
they don't, typing "protected" by hand is not really a challenge.
But thanks for the suggestions, I had not even thought about the
wrapping template mixin before.
If you or someone else are really unhappy with those decisions,
feel free to argue against them ;-) .
Best regards,
Robert
