Arcane Jill wrote:
> [...] perhaps someone can enlighten me.
> 
> 1) What the hell is a Wiki?

A website that anybody can edit, basically.  The first one is the Portland Pattern Repository, which can be found at <http://c2.com/cgi/wiki>

(incidently, there's loads and loads of awesome stuff buried in there. it's not hard to dive in and come back out with gray hair)

> 2) Why is it called "wiki"?

<http://c2.com/cgi/wiki?EtymologyOfWiki>

> 3) How do you add pages to it, edit it, etc?
> 4) What's to stop spammers and site-vandals from doing (3)?

The biggest reason WhyNobodyDeletesWiki <http://c2.com/cgi/wiki?WhyNobodyDeletesWiki> is because it's so very easy to undo.  Every wiki I know of stores changes made in the last few weeks or so, so anybody at all can undo it, and there are generally quite a lot more people interested in fixing it than breaking it. :)

> 5) If I click on Edit, I see a plain text entry box in some weird non-HTML
> format I don't understand. What format is this?

Wikis have their own FormattingRules
<http://c2.com/cgi/wiki?TextFormattingRules>

Anyway, I'm sure you get the idea.  It really is as simple as it sounds. :)

 -- andy

David Barrett wrote:

> But Postconditions elude me:

It is design-by-contract: Both, pre- and post-conditions are part of the *interface*. There are several aspects to that fact. In D, there seems to be very little distinction between interface and implementation, both being coded in the same file. I believe, though, that it is possible to extract the interface of a given module, using the compiler.

In that case, the pre- and post-conditions should be put into the interface as well. They document how a function is to be used, and what it produces. It is understood, that pre- and postconditions should only ever depend on public functions and the function arguments.

One important aspect of pre- and post-conditions is, that they are inherited along with the interface. (The the chapter "contracts") An overriding function must keep the contract of the original. It my loosen the in-contract or tighten the out-contract.

Plain asserts in the body, on the other hand, have nothing to do with contracts, but are merely a kind of "checked documentation", helping in understanding the implementation code correctly.

Whether design-by-contract helps you in avoiding bugs depends on your coding style. It certainly is only interesting for libraries and larger projects that define clear interfaces between individual parts. For small projects, thinking about clear interfaces often is more effort than it is worth.

Arcane Jill wrote:

>>But Postconditions elude me:
>>It seems of very low value for a method to test its own output: that's
>>like the fox guarding the henhouse.
> 
> Really? I find postconditions most useful of all. In the Int class (etc.bigint.bigint) they're used all the time. For example - there's a function which, given input x, returns the integer square root y of x, and the remainder r. The postcondition asserts that (y*y+r == x).

It is more than that. For finding your own bugs, a plain assert would be good enough. The post-condition is more like a promise to the outside world. You are telling publicly: this function will do that. Better than any comment: the promise can even be checked.

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:cco50m$27n6$1@digitaldaemon.com...
> Whether design-by-contract helps you in avoiding bugs depends on your
coding
> style. It certainly is only interesting for libraries and larger projects that define clear interfaces between individual parts. For small projects, thinking about clear interfaces often is more effort than it is worth.

True enough. One aspect of D that sometimes is controversial is I wanted to make it easy to write quick-and-dirty programs as well as provide the scaffolding for large, complex projects. That's why, for example, 'public' is the default access rule for class members, and object.d is implicitly imported. DbC is a waste of effort for Q&D programs, which is why it is optional.