Should I prefix package names with the name of my program?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jan 30 17:57:29 UTC 2019


On Mon, Jan 28, 2019 at 05:07:35PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/28/19 4:57 PM, Steven Schveighoffer wrote:
> > On 1/28/19 3:16 PM, H. S. Teoh wrote:
[...]
> > > > I use a package nearly every time because if you don't, you run
> > > > into weird quirks of the language for top-level modules.
> > > 
> > > Really? Such as?  I've never heard of said quirks.
[...]
> OK, so it's because top-level packages and modules imported are put
> into the namespace. But modules under packages are not.
> 
> So for instance, if you have:
> 
> module a;
> 
> void a() {}
> 
> ----
> 
> import a;
> 
> void main()
> {
>    a(); // error can't call module a
> }
> 
> whereas if a is changed to:
> 
> module pkg.a;
> 
> void a() {}
> 
> and the import changed to import pkg.a; then it works.

Argh... I've been running into this problem *so* often, that I've
settled with deliberately naming modules differently from any symbols
contained therein.  So *this* is what I've been doing wrong... sigh...


> But this doesn't solve the problem of having a simple library/app with
> a simple module name. What do you put it under? It can't be a.a,
> because that doesn't help.
> 
> It really is a quirk of D that I don't like, the top level packages
> should not conflict with other symbols in most cases.
[...]

I'm guessing this has to do with D's symbol lookup rules. Yet another
"counterintuitive" case for Walter's highly-symmetric, idealistic lookup
rules. :-P


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.


More information about the Digitalmars-d-learn mailing list