Speeding up importing Phobos files
Mike Franklin
slavo5150 at yahoo.com
Fri Jun 7 15:34:22 UTC 2019
On Friday, 7 June 2019 at 14:45:34 UTC, H. S. Teoh wrote:
> The flip side of this coin is that having one file per module
> helps with code organization in typical use cases. As opposed
> to the chaotic situation in C/C++ where you can have one .h
> file with arbitrary numbers of .c/.cc files that implement the
> function prototypes, with no obvious mapping between them, or
> multiple .h files with a single amorphous messy .c/.cc file
> that implements everything. Or where there are arbitrary
> numbers of modules nested inside any number of .c/.cc files
> with no clear separation between them, and where filenames bear
> no relation with contents, making code maintenance challenging
> at best, outright nightmarish at worst.
What I'm proposing is that a library's organization can be one
file per module while it is being developed, but once it is
published for consumption by others all packages/modules are
concatenated into one file so it's faster for users to import.
Or you could even concatenate some packages/modules, but not
others depending on how users typically interact with the library.
There may be use cases (like mine with the memory-mapped IO
registers) where users may want to actually develop with more
than one module per file. Or when one wants to share
multi-package/module cut-and-pastable code examples. But those
are special cases.
What's nice is that it changes nothing for users today. It just
removes an arbitrary limitation to help improve import speed
while enabling some more flexibility for those who may it.
Mike
More information about the Digitalmars-d
mailing list