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

On Thu, Sep 16, 2010 at 10:16 AM, Sean Kelly <sean at invisibleduck.org> wrote:

> For weird cases like this, I'll put prototypes with the documentation in a version(DDoc) block.  It means more maintenance though.
>
>
Right.  In other words it kinda defeats the purpose of automatic doc generation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100916/4fbdfc77/attachment.html>

How about after the deployment of DMD 2.049 arrange Phobos with the desired layout, then fix tool issues from using that layout.

We embrace that does not choose rule over practicality. So we can say Phobos is a flat system, but break that for good reason such as std.container and std.algorithm. How they should be broken up is another subject.

On Thu, Sep 16, 2010 at 6:52 AM, David Simcha <dsimcha at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100916/8c8d035d/attachment.html>

On Wed, 15 Sep 2010 22:25:31 +0900, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:

> On Wed, 2010-09-15 at 22:08 +0900, Masahiro Nakagawa wrote:
>>
>> 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?

I think AddressInfo and related functions are not a part of socket.
If anything, these functions seem to be networking operations.
But unfortunately, Phobos doesn't have such modules...

On 9/15/10 6:56 AM, 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

Done.

>          std.boxer      - superseded by std.variant

Done.

>          std.contracts  - superseded by std.exception

Not yet.

>          std.cstream    - superseded by std.stdio.File

Not yet - waiting for the new streams.

>          std.demangle   - superseded by core.demangle

There's no http://www.digitalmars.com/d/2.0/phobos/core_demangle.html. Walter, Sean?

>          std.iterator   - superseded by std.range

That's been eliminated for a while. Looks like Walter didn't update std.ddoc before generating the docs. Walter?

>          std.openrj     - obscure format, better to use std.json

Can't find it.

>          std.perf       - superseded by StopWatch

Can't find it.

>          std.regexp     - superseded by std.regex

Deprecated.

>          std.stream     - ranges are the way to go

Wating for the new streams.

>          std.syserror   - superseded by std.windows.syserror

Can't find it.

>          std.c.*        - superseded by core.stdc.* and core.sys.*

Walter, Sean? Are we ready for this step?

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

If anyone wants to work on this, please discuss.

> And finally, some renaming suggestions (which were actually posed by
> Andrei):
>
>          std.conv ->  std.convert
>          std.stdio ->  std.io

I guess we can leave these alone.

> 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

Looks good to me. There's no std.osx to complement the other two.


Andrei