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

Bill Baxter wbaxter at gmail.com
Thu Nov 6 23:48:17 PST 2008


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



More information about the Digitalmars-d mailing list