Templating everything? One module per function/struct/class/etc, grouped by package?

[JR via Digitalmars-d-learn]

On Monday, 12 May 2014 at 09:16:53 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> Well, that would be a lot of extraneous files, which would be 
> very messy IMHO.
> It also makes it much harder to share private functionality, 
> because
> everything is scattered across modules - you'd be force to use 
> the package for
> that. It also wouldn't surprise me if it cost more to compile 
> the code that
> way if you were actually using most of it (though it may very 
> well save
> compilation time if you're using a relatively small number of 
> the functions
> and types). So, from a purely organization perspective, I think 
> that it's a
> very bad idea, though others may think that it's a good one. 
> And since
> package.d imports all of those modules anyway, separating them 
> out into
> separate files didn't even help you any.

Thank you for answering. The package.d example was mostly to 
highlight that the current syntax and practice of importing 
everything in a package wouldn't change.

To be a bit more specific I'm new to everything beyond advanced 
scripting, so my code has grown organically. Partly due to 
shotgun programming, and partly due to exploratory programming. 
In the process of figuring out what code depends on what, to 
allow for making pieces of it more self-contained, I realized 
that with my current practice of gathering everything related to 
the same topic into one module made it all unneccesarily tangled. 
(--gc-sections seems to cause segfaults.)

As an example, both the homebrew string builder 'Yarn' and the 
simple 'string plurality(ptrdiff_t, string, string)' belong in 
mylib.string. But if I want to reuse only plurality there in 
other projects I would end up pulling in all the ancillary stuff 
Yarn needs to validate input, and it only segways from there. 
Correct?

The logical step would be to split the all-encompassing 
mylib.string module into submodules, and the logical followup 
question would be why I shouldn't do that everywhere. Knowing 
that templates aren't built unless concretely instantiated, the 
idea of templatizing everything fell into the same basket.

I hope you understand my concerns that I was falling into an 
anti-pattern.