I don't mind large files, what I don't like are large functions. Formatting the file well can help too, like having easily visible boundaries between types of functions.
On Sep 16, 2010, at 7:03 AM, Jacob Carlborg wrote: > Yes, since we have public imports it's Ddoc that needs an enhancement. Glad > I'm not the only one that doesn't like modules with 6K lines of code. But > wouldn't it be so much worse having to look at a documentation that is more > fine grained (with sub packages) then a documentation that is based on a flat > module hierarchy? There could be a short description or summary in the module > that publicly imports all modules in the package that describes the whole > package. > > /Jacob Carlborg > > On 16 sep 2010, at 15:52, 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 > > -- > /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
