For weird cases like this, I'll put prototypes with the documentation in a version(DDoc) block. It means more maintenance though.
On Sep 16, 2010, at 6:52 AM, David Simcha wrote: > I'd like to see a way to make Ddoc produce documentation for the public > imports of a module. This way we could make a simple, coarse-grained import > system for the user (i.e. import std.container and you've got every container > you could possibly want), but have each container be implemented in its own > file in std.containerimpl.somecontainer for development convenience and > publicly imported by std.container. The only major problem I see with this > is Ddoc, as mentioned above. > > The bottom line is that, when using D, I hate being forced to write tons of > import statement boilerplate to do anything non-trivial (what you get if you > make the import system fine-grained) but when developing Phobos I hate having > to scroll through 6,000 line files like std.algorithm (what you get when you > make the import system coarse-grained). I'd like to clean this up from the > developer's perspective, but in a way that's transparent to the user. > > On Thu, Sep 16, 2010 at 9:46 AM, Jacob Carlborg <d...@me.com> wrote: > I don't think it's the number of modules that makes it hard, it's because of > the organization of the modules. Too many modules in one package (std) and > too much code in one module. Take std.container for example, every container > type in on module, that's just insane. It should clearly be, in my opinion, a > container package (or actually I would prefer it to be called collection) and > one module per container type. std.container is almost 3500 LOC and have four > (or something like that) container types, what happens when (if) we get more > container types like different types of trees and other containers, just put > everything in std.container? That is just too much code in one module. Just > my opinion. > > > /Jacob Carlborg > > On 16 sep 2010, at 15:30, Lars Tandle Kyllingstad wrote: > > > I disagree, I like the flat hierarchy. > > > > And just to clarify my earlier e-mail, for which I may have chosen a bad > > subject: I do not think that the number of modules in Phobos is too > > high in general. I think it has too many *obsolete* modules, and too > > many modules with very limited functionality. > > > > If we got rid of the cruft that has been accumulating, and merge some of > > the smaller modules into larger ones, Phobos would seem a lot less > > unwieldly. > > > > -Lars > > > > > > > > On Thu, 2010-09-16 at 14:54 +0200, Jacob Carlborg wrote: > >> I think it's time for Phobos to start using sub packages and drop the flat > >> module hierarchy. > >> > >> On 15 sep 2010, at 13:56, Lars Tandle Kyllingstad wrote: > >> > >>> I said in an earlier e-mail that I think std.file, std.path, and > >>> std.stdio should remain separate modules. However, I do think that, for > >>> a library with a flat module hierarchy, Phobos has acquired way too many > >>> modules. Some of them should (and will) be removed, and some could be > >>> merged. > >>> > >>> The following are my suggestions for how to trim the Phobos module list > >>> a bit. At the bottom I'll show the resulting module list. > >>> > >>> > >>> Modules which could be removed, most of them *right now*, because they > >>> are superseded by other modules or built-in functionality: > >>> > >>> std.bind - use lambdas or nested functions instead > >>> std.boxer - superseded by std.variant > >>> std.contracts - superseded by std.exception > >>> std.cstream - superseded by std.stdio.File > >>> std.demangle - superseded by core.demangle > >>> std.iterator - superseded by std.range > >>> std.openrj - obscure format, better to use std.json > >>> std.perf - superseded by StopWatch > >>> std.regexp - superseded by std.regex > >>> std.stream - ranges are the way to go > >>> std.syserror - superseded by std.windows.syserror > >>> std.c.* - superseded by core.stdc.* and core.sys.* > >>> > >>> Modules for which there is no documentation on the D home page, and > >>> which I suspect nobody are using: > >>> > >>> std.loader > >>> std.stdarg > >>> std.typelist > >>> > >>> Modules which can be merged into a single one, possibly after > >>> substantial/complete rewrites: > >>> > >>> std.compiler + std.cpuid + std.system (= std.sysinfo?) > >>> std.ctype + std.uni (= std.character?) > >>> std.date + std.dateparse + std.gregorian + std.stopwatch > >>> (= std.datetime?) > >>> std.encoding + std.utf (= std.encoding?) > >>> std.socket + std.socketstream (= std.socket (or std.net?)) > >>> std.typecons + std.typetuple (= std.types?) > >>> > >>> And finally, some renaming suggestions (which were actually posed by > >>> Andrei): > >>> > >>> std.conv -> std.convert > >>> std.stdio -> std.io > >>> > >>> > >>> All this gives us the following, nice and short (well... shorter, at > >>> least) module list: > >>> > >>> std.algorithm > >>> std.array > >>> std.base64 > >>> std.bigint > >>> std.bitmanip > >>> std.character > >>> std.complex > >>> std.concurrency > >>> std.container > >>> std.convert > >>> std.datetime > >>> std.encoding > >>> std.exception > >>> std.file > >>> std.format > >>> std.functional > >>> std.getopt > >>> std.intrinsic > >>> std.io > >>> std.json > >>> std.math > >>> std.md5 > >>> std.metastrings > >>> std.mmfile > >>> std.numeric > >>> std.outbuffer > >>> std.path > >>> std.process > >>> std.random > >>> std.range > >>> std.regex > >>> std.signals > >>> std.socket > >>> std.stdint > >>> std.string > >>> std.sysinfo > >>> std.traits > >>> std.types > >>> std.variant > >>> std.xml > >>> std.zip > >>> std.linux > >>> std.windows > >>> > >>> > >>> Just something to think about. > >>> > >>> -Lars > >>> > >>> _______________________________________________ > >>> phobos mailing list > >>> phobos@puremagic.com > >>> http://lists.puremagic.com/mailman/listinfo/phobos > >> > > > > > > _______________________________________________ > > phobos mailing list > > phobos@puremagic.com > > http://lists.puremagic.com/mailman/listinfo/phobos > > -- > /Jacob Carlborg > > _______________________________________________ > phobos mailing list > phobos@puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos > > _______________________________________________ > phobos mailing list > phobos@puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list phobos@puremagic.com http://lists.puremagic.com/mailman/listinfo/phobos
