Suggestion for DUB users: The vanity package
geod24 at gmail.com
Tue Oct 19 04:03:38 UTC 2021
I was looking at a few packages recently, and noticed a bothering
trend: Single-module libraries ending up at the top level.
Why is it bothering ? Well, here's a little puzzle: Does the
following code compile?
void main ()
The answer is "maybe". In most case, it will not. However, if the
file this resides in is named `foo.d`, it will compile. Because
the module name accounts for an identifier that can be addressed
in the scope of the module (and other modules that import it).
Now imagine what would happen if `core.atomic` or `core.time`
were top-level modules ? Conflicts, conflicts everywhere. It only
gets worse with imports, as `import atomic;` would insert the
`atomic` name into the current scope, which would then shadow any
symbol named `atomic` in any import (there used to be an evil
hack in the compiler to make this special case work - it is gone
since a few releases).
So what's the solution ? Well we could go with the Java-esque
`com.foo`, but that'd be a bit ridiculous. Instead, for a few
years now, I have started a habit of using the "vanity package",
a top-level package with my username, for simple libraries I
It "just works", is pretty simple to remember, easily extendable,
and you can be pretty sure no user of your library will run into
conflicts. I encourage anyone considering publishing a package to
do the same.
More information about the Digitalmars-d