Robert Jacques wrote:
On Fri, 29 Jan 2010 15:18:14 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to browse through all that
documentation. I wonder how we could break std.algorithm into smaller
units (which is an issue largely independent from generalizing the
algorithms now found in std.string).
Any ideas are welcome.
Andrei
I like how naturaldocs, which is similar to ddoc helps with this: by
adding a group tag. See this example of a summary of a class:
http://www.naturaldocs.org/documenting/reference.html#Example_Class
Probably it is possible to come up with categories for algorithm like:
- functional tools
- searching and sorting
- string utilities
...
Arguably a more D like alternative is to make std.algorithm a
package and each 'category' a module of that package.
I think the idea of tags is awesome, particularly because it doesn't
require one to divide items in disjoint sets. I'll think some more of
it. It might require changes in ddoc. At any rate, sounds like a D3
thing. Until then, I think I'll add to std.algorithm in confidence
that we can scale the documentation later.
Andrei
By the way, in the sort term you could greatly improve the usability of
std.algorithm by cleaning up the index ("jump to") at the top of the
file. A simple alphabetical listing would be great and you could easily
start grouping links under categories (which would eventually become tags)
That jump to index is automatically generated. I can have it sorted
alphabetically, which makes sense for large lists. But then should I
also list components in alphabetical order?
Andrei
