Removing ddoc and unittest [Was: Re: How does D improve...]

[Ary Borenszweig]

Bill Baxter wrote:
> On Fri, Nov 7, 2008 at 4:34 PM, bearophile <bearophileHUGS at lycos.com> wrote:
> 
>> ddoc: the -D compilation switch of DMD can be removed, as well as the code that it contains to generate the HTML page. All such code can be moved into a library (and later improved/debugged). A little program can be added into the "bin" directory that is designed just to create such HTML pages. But there's a problem here: such tool has to parse D code, etc, so it's a duplication of efforts, with a risk of growing little differences in the way D code is parsed, etc., that's bad. So the DMD compiler can grow a switch that makes it spit out the result of parsing a D module (for example in Json file format), that such ddoc tool can load (with a pipe too, to avoid putting another file on disk) and use avoiding all the parsing and creating the HTML.
> 
> Ddoc's output is supposed to be entirely determined by the macro set
> that you give it.  In theory anyway.
> So it should be possible to write a ddoc macro set that can spit out
> your Json format version of all entities and their DDoc documentation
> strings.
> It may not be possible in practice, but I think bug reports on what's
> missing to make that a reality are less likely to get ignored than
> ones suggesting that DDoc be removed.
> 
>> unittest: here I am less sure about what it needs to be done (beside removing the -unittest compilation switch from DMD). I think D has to grow few more handy reflection capabilities, that can be used to write short and a simple unittest library for the standard library. A unittests(name) {} syntax may be kept in the language... I am not sure.
> 
> Someone who's a big unittesting fan should write up a proposal on
> this.  I think unittests are neat and all -- I probably don't use them
> as much as I should -- but I don't really know what's so great about
> named unittests or other things people mention that D's unittests
> lack.  I suspect Walter may be in the same boat.  You can't address a
> problem if you don't really understand it.
> 
> --bb

I write unit tests all the time in Java, both for projects in my work 
and for projects outside the work (Descent, for instance). I make a 
class named FooFixture or FooTests to test the Foo class. Each method of 
FooFixture shows the intention of the test. Each method of FooTests 
class is a test. If a test "ShouldDoSomething()" fails, I can see in the 
UI: "ShouldDoSomething() failed, together with a stack trace.". So if I 
change something in my code, I can know at a glance which tests failed, 
and probably understand why. This is not possible to achieve if you get 
"assert failed, blah blah, at line 8 of foo.d". If I see that many tests 
failed, I can get a better understanding of what I broke and why. In D I 
see just one failed assertion and that's it, I can't see all of the 
parts that the problem has affected.

That's why I think named unittest blocks and continue on assertion 
failed are useful.

As for ddoc, I wish there were a way to say "link to some declaration". 
In Java you have the @link{} tag, in C# the <see cref=""/> tag (I 
think). When you write documentation, understating declarations it 
participates with helps understanding the overall picture. There's 
currently no way to insert links to other declarations, and that makes 
it hard to navigate ddocs. This also applies for declarations found in 
parameters, base classes and implemented interfaces, etc.