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

On Wed, 15 Sep 2010 20:56:14 +0900, Lars Tandle Kyllingstad <lars at kyllingen.net> 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.

I agree.

> 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.*

The content of std.stdint is "public import core.stdc.stdint;" only. I think this module doesn't need.

> 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?)

std.socket should be divided into std.socket, std.event and
std.net(std.dns?).
I said this point in "Breaking changes for std.socket improvement".


Masahiro

On Wed, 2010-09-15 at 22:08 +0900, Masahiro Nakagawa wrote:
> On Wed, 15 Sep 2010 20:56:14 +0900, Lars Tandle Kyllingstad <lars at kyllingen.net> 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.
> 
> I agree.
> 
> > 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.*
> 
> The content of std.stdint is "public import core.stdc.stdint;" only. I think this module doesn't need.

Oh, I didn't know that.  Then it should go too.


> > 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?)
> 
> std.socket should be divided into std.socket, std.event and
> std.net(std.dns?).
> I said this point in "Breaking changes for std.socket improvement".

I don't mind splitting modules either, as long as it is a sensible split. :)  I agree that std.event deserves its own module.  But what would you put in std.socket, and what would you put in std.net?

-Lars

Dear Mr. President, There are too many states nowadays. Please eliminate
three.
P.S. I am not a crackpot.

    -- Grandpa Simpson

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

-- 
/Jacob Carlborg

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
> 

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100916/c737ae0d/attachment-0001.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100916/c8a9b142/attachment.html>

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 <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