On Saturday 20 November 2010 08:03:52 Jacob Carlborg wrote:
> Why don't you use delegates instead of string mixins? For example,
> assertExcThrown, could take a delegate which calls the function you want
> to test instead of a string that represents the call. The mixin want be
> needed as well. Am I missing something?
Well, delegates wouldn't be a bad idea, but they're unwieldy too. Would you
rather write
assertExcThrown!Exception((){func(param1, param2);});
or
mixin(assertExcThrown!(Exception, `func(param1, param2)`));
The delegate would be less efficient, but you could reduce code duplication by
going that route, since then __FILE__ and __LINE__ could be default parameters
to assertExcThrown!(). It would also make it so that __FILE__ and __LINE__
could
be replace if you reall wanted to (which could be useful), but you could do
that
by changing it so that the mixin version of assertExcThrown!() took __FILE__
and
__LINE__ as default parameters instead of them being internal to the mixin.
Neither is pretty, but they both have their pros and cons. It looks like if I
do
keep the mixin version, I should probably move __FILE__ and __LINE__ to
parameters instead of mixing them in directly, so that it's more flexible. I
suppose that you could just make the function call parameter a lazy one and
templatize assertExcThrown!() on the return type of the function (I _think_
that
that would still work with void). That way, you could avoid having to type
(){;}
around the function call. In a way though, it is a bit silly to declare it as
lazy, since it _always_ gets called. That could be the best way to go though.
Honestly, it never even occurred to me to make it a delegate. I was originally
trying to pass the function and its arguments separately, and that didn't work
as well as I'd have liked, and the mixin solution is what I arrived at. I do
find
having to pass a delegate uglier than having to use a mixin, but that's
probably
pretty subjective and debatable. Using delegates will make for less efficient
unit
tests, but it would mean less code duplication, and thus faster compilation.
So,
it's not entirely a straightforward choice, I think.
The lazy solution sounds pretty good actually. Can anyone think of any real
downsides to that? So, it would look something like
assertExcThrown(E : Throwable, T)(lazy T, string file = __FILE__, size_t line =
__LINE__);
- Jonathan M Davis
