Speeding up importing Phobos files

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jun 7 14:45:34 UTC 2019


On Fri, Jun 07, 2019 at 09:47:34AM +0000, Mike Franklin via Digitalmars-d wrote:
[...]
> It would also help with a number of other helpful patterns.  For
> example, I currently use the following pattern for creating register
> maps of memory-mapped IO:
> 
> ---
> final abstract class MyRegisterBank
> {
>     final abstract class MyRegister
>     {
>        //static properties for bit-fields
>     }
> }
> // See https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/spi.d
> for the real thing
> ---

Why final abstract class? If all you have are static properties, you
could use structs instead.

Though of course, it still doesn't really address your fundamental
concerns here.


[...]
> It seems like an arbitrary limitation to have the package/module
> system hard-coded to the underlying storage technology, and removing
> that limitation may help with the import speed while also enabling a
> few interesting use cases.
[...]

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.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds


More information about the Digitalmars-d mailing list