CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2012-01-02 00:14, Jonathan M Davis wrote:
> On Sunday, January 01, 2012 15:35:00 Jacob Carlborg wrote:
>> Ok, if you would rather have all this in the language I would say no do
>> that. But I know other people in the community that usually prefer to do
>> a library solution if possible.
>
> If all we're talking about is named unit tests and running all of the unittest
> blocks within a module even if one fails, those aren't huge changes to the
> language. Both have been discussed before, and the only reason that the latter
> hasn't been implemented yet is that it requires changes to the compiler. So, I
> don't see any reason to make those a library solution. If we're talking
> something massively more complicated than that, then yes, a library solution
> starts making more sense. I also think that it then doesn't necessarily make
> sense to put it in the standard library.
>
> If the issue is how the tests print out on failure, that could probably be
> done in the language as well, depending on what you were talking about
> changing. If you want to do something massively complicated, however, then
> you'd probably have to come up with a library solution, but again, I see no
> reason to have it in the standard library if you're doing anything fancy with
> how the test failures print out.
>
> - Jonathan M Davis

I see it as three things I want done.

* Named unit tests
* Continue to run unit tests after a failed one
* A nice report at the end, preferably configurable

It would be nice if the first two were implemented in the language. If 
the third one is implemented in the runtime it could perhaps be 
configurable. One implements an interface, or similar, and can output 
the unit test report how he/she wants.

-- 
/Jacob Carlborg