On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote:
On 2011-12-25 04:05, zhang wrote:
On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright
<newshou...@digitalmars.com> wrote:
On 12/22/2011 11:25 AM, Piotr Szturmaj wrote:
I wish D could support partial modules - partial as analogy
to C#'s
partial
classes.
module std.datetime-unit1;
import std.datetime-unit2;
// dash allowed only in submodules with the same module name
...
module std.datetime-unit2;
import std.datetime-unit1;
...
// then
module whatever;
import std.datetime; // as usual
I have no idea why anyone would want this. (Is it because
the file is
too big to fit on a floppy disk?<g>)
As for big module, my solutions are:
1) put related modules into a package (or directory)
2) add a module named all.d into the directory, and this
module will import all the other modules publicly
3) now just import the *all* module when needed
Here we have yet another example of some one who wants to use
"import foo.*;".
I agree it would be nice to have a proper way to do this.
Providing .all modules feels hacky and they need to be manually
maintained - it also doesn't look as good.
The _really important thing_ to note here is, there are at least
two kinds of D libraries when it comes to this issue. Some
libraries, including Phobos, prefer putting a lot of stuff in one
module rather than splitting it up into a package. But many other
libraries prefer splitting a library over multiple modules and
using the package system to tie them together.
Arguing over which approach is better comes down to a wide range
of arguments, many quite subjective. I do not believe either
approach is always better than the other. But I do believe it's
important not to disregard the package approach, because it has
advantages and adherents as well.
Right now, the language favours the single module approach. When
packages are used instead, it's clunky to provide a convenient
interface to the entire library, and it's not very intuitive to
look for a ".all" module, which could be named anything.
I really like the idea of simply adding "import myPackage;",
behaving like your average ".all" module.
Doing it this way solves at least three problems: No more clunky
maintenance of convenience modules, big modules can later be
split up into a package without breaking any client code, and we
don't have to worry about a ".all" module for Phobos anymore
(which is a suggestion that has been on the table several times).