Cross referencing in Ddoc
Jacob Carlborg
doob at me.com
Tue Dec 31 04:26:03 PST 2013
On 2013-12-31 01:05, Sönke Ludwig wrote:
> Also, the official first four goals of DDOC are:
>
>> 1. It looks good as embedded documentation, not just after it is
>> extracted and processed.
It certainly does not. Just have a look at the top of std.algorithm or
std.uni. Hundreds of lines of Ddoc madness.
>> 2. It's easy and natural to write, i.e. minimal reliance on <tags> and
>> other clumsy forms one would never see in a finished document.
Fails again. As soon as you need something more advanced than the
standard sections you need to use macros. The macros are just as tags,
just with a different syntax and name.
>> 3. It does not repeat information that the compiler already knows from
>> parsing the code.
You sure need to do if you want good documentation. Take a look at
std.algorithm, it has over 300 lines of Ddoc code to create a symbol
table that Ddoc should be able to automatically generate.
>> 4. It doesn't rely on embedded HTML, as such will impede extraction
>> and formatting for other purposes.
As far as I know this isn't very useful. For the other formats we use,
like PDF, it uses the HTML output as a base.
To me it looks like it failed on all four of these goals.
> Using $(XREF), $(TABLE $(TR $(TD ...))), $(LINK a b) $(D ...) and so on
> is nothing but markup. If we go that route, we could as well remove all
> syntax, except for the macros:
>
> $(SUMMARY ...)
> $(SECTION See_Also
> ...
> )
> $(PARAMS
> $(PARAM x ...)
> $(PARAM y ...)
> )
> $(SECTION Example
> $(CODEBLOCK
> ...
> )
> )
>
> But you added the syntax for a reason back then (readability ...and
> writability). And the same goes for the auto-detection of identifiers. I
> think the only problem is that the default would have been better off
> the other way around.
>
I completely agree.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list