On 2011-12-25 15:31, Jakob Ovrum wrote:
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).

I'm not sure if I like that syntax because you wouldn't be able to tell the difference between importing a package and a module. But perhaps that's the point. Otherwise I agree.

--
/Jacob Carlborg

Reply via email to