On 2013-11-08 11:22, Robert wrote:
I agree that template mixin syntax is a bit nicer, but I ran into a few
issues with them. In the end I settled with the string mixin, because it
avoids those issues and also was more powerful (User can now choose the
protection). How would your template mixin wrapper look like?
Just take the same arguments as the "signal" function, something like:
template signal (string name, string protection, Args...)
{
mixin(signalImpl!(Args)(name, protection));
}
Oh, quite the other way round, the public in the assert list is quite
unnecessary. If you want to go public/export just use "none" as
protection and set it yourself, like:
public {
mixin(signal!(string, int)("valueChanged", "none"));
}
If that works, why do you have the option to specify the protection at all?
BWT, shouldn't that assert be static?
--
/Jacob Carlborg
