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

[Bill Baxter]

On Fri, Nov 7, 2008 at 4:48 PM, Bill Baxter <wbaxter at gmail.com> 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.

BTW, another thing I think would be cool to do with DDoc (or try to,
anyway) is to create a macro set that generates something like header
files with documentation.  Basically .di files, but .di files meant
for humans to read, including all ddoc comments and formatted
sensibly.


--bb