[phobos] Phobos has way too many modules
Sean Kelly
sean at invisibleduck.org
Thu Sep 16 07:17:32 PDT 2010
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 <doob at 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 at puremagic.com
>> >>> http://lists.puremagic.com/mailman/listinfo/phobos
>> >>
>> >
>> >
>> > _______________________________________________
>> > phobos mailing list
>> > phobos at puremagic.com
>> > http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> --
>> /Jacob Carlborg
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
More information about the phobos
mailing list