module keyword with curly brackets

[H. S. Teoh via Digitalmars-d]

On Sat, Nov 01, 2014 at 03:23:17PM -0700, Walter Bright via Digitalmars-d wrote:
> On 11/1/2014 6:31 AM, Dicebot wrote:
> >I am afraid you need to get used to it because it is fundamental
> >design decision of D module system and quite a feature on its own.
> >Lot of files == awesome.
> 
> Cramming lots of code into one source file made abundant sense on
> floppy disk systems, because switching files was so painfully slow.
> 
> Of course, that problem disappeared 30 years ago.
> 
> Nevertheless, Phobos has an obese kitchen-sink module problem anyway,
> so it's clear that those who want to cram it all into one file have
> any difficulties doing it :-)

I've tried on one or two occasions to split std.algorithm into more
manageable submodules. Unfortunately, it's not a trivial task due to
over-reliance on module-global imports. Currently, it's so bad that I
can't even run its unittests on my 1GB RAM 6-core CPU system anymore; I
have to comment out two particularly memory-hogging unittests in order
to not have the test abort prematurely with OOM. (Truth be told, though,
it's partly my own fault -- the offending unittests are problematic
because they trigger an exponential number of template instantiations in
the 3rd overload of cartesianProduct, authored by yours truly. :-P I'm
still trying to work out a way of preventing exponential template
instantiations in that particular overload, which is non-trivial because
it deals with infinite ranges.)

We need a team of volunteers to tackle the behemoth that std.algorithm
has become, and cut it back down to manageably-sized chunks.

Jonathan was also reportedly working on breaking up std.datetime into
manageable pieces, but it's been a long time and so far it seems to have
been far easier said than done.

So yeah, I'd say we have an obesity problem on our hands. :-P


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg