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
