Why I'm hesitating to switch to D

Walter Bright newshound2 at digitalmars.com
Wed Jun 29 20:57:14 PDT 2011


On 6/29/2011 3:56 PM, KennyTM~ wrote:
> The easier, nicer, and more productive part:
> - Native support of sectioning and anchors instead of sprinkling with <h3> and
> <a name>'s.

In Ddoc, you can define your own macros to do that, for example:

     H3=<h3>$0</h3>

and then:

     $(H3 This is a Header 3)

There is no reason whatsoever you are stuck with the defaults.

> Linking is also more natural.

What if the link points to another file? And what if sometimes you want it 
intrafile, and another time interfile, without changing the source text?

And what if, for the unordered list, you wish to add a "class=foo" attribute for 
one of them, and "class=bar" for another?


> - One could use an external Turing-complete parser (in Python, though) for some
> special block of documentation, e.g. the grammar list, instead of having to hack
> the macro system for the result. The latter is like having to highlight the D
> code using $(RED x) $(GREEN x) $(BLUE x) manually.
> - Writing reST is really like writing document. Writing DDoc is like writing Lisp.
> - reST has better support than DDoc is many aspects (output format, stylesheets,
> plugins, documentations, etc.).

Let's say I have some C++ code, C code, and ASM code, and want them to use 
different css classes. In Ddoc, I'd do:

$(CCODE
... C code ...
)

$(CPPCODE
... C++ code ...
)

$(ASMCODE
... asm code ...
)

and by defining the macros, I can set them to use div's, pre's, whatever 
attributes I want, and do this as many times as I need to for ALL of the constructs.

Generally, how good or how bad your Ddoc source looks like depends on how you've 
defined the macros.


More information about the Digitalmars-d mailing list