CURL Wrapper: Congratulations Next up: std.serialize

[Tobias Pankrath]

Jonathan M Davis wrote:

> On Saturday, December 31, 2011 11:05:58 Tobias Pankrath wrote:
>> > I think that the AssertError's message (which includes the file and
>> > line number of the failure) and its stack trace are plenty. It's
>> > exactly what you need and nothing else.
>> > 
>> > - Jonathan M Davis
>> 
>> I want to have such a summary.
> 
> I don't see any reason to put that in the standard library. 

I do see any reason not to put in the standard library. On the contrary:
not having one in the standard library prohibits phobos modules to
use an advanced solution.

> If you want that sort of summary, you probably want it printing stuff out
> on success too, and that definitely goes against how the built-in
> framework works (since it follows the typical unix approach of failure
> printing out stuff and success printing nothing). 

If I want to run the program only for the units tests, yes. But this does
not touch the questions, whether or not to put a unit test framework in
the stdlib.

> So, I think that that
> really makes more sense as a 3rd party solution rather than as part of the
> standard library. 

Since unit tests found their way in the language, I really see no reason,
why they are no fit for the standard lib.

What does a library qualifiy for phobos?

> And in general, 3rd party solutions are more likely to
> be customizable in a way you'd like rather than picking a single way of
> doing things.

Quality of other standard libraries shouldn't be an upper bound for phobos.

> D's unit test framework isn't designed that way at this point. 
I wouldn't say that D has an unit test framework right now. I has merely a 
way to run code at startup. 

> You need
> named unit tests for that to really make sense. It could theoretically be
> added and would be nice, but that would require changes to the language
> (though fortunately, they would be backwards compatible changes). So, we
> may see that eventually but not right now. At this point, the closest that
> you get to that is to unit test each of your modules separately rather
> than all at once. 
Thats my line, we are lacking features and we could have a good library 
solution for this.

> So, I'm not sure how common being
> able to really run a single unit test is anyway. 

I always run all of them and if one fails, I'll want to run those that 
failed to examine why they failed.

I agree that we shouldn't add complexitiy to the buildin language unit 
tests, apart from some additions that you mention. But we should define
a way, how an advanced unit test framework should operate with the
core feature and of course they should work together.

And since it is something many want to use (look at unit tests frameworks
in other languages), it does have its place in the stdlib.


PS: My newsreader (the KDE newsreader from kontact) seems to kill threading. 
Does anyone know how to change this without changing the newsreader?