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