www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Should I prefix package names with the name of my program?

reply Victor Porton <porton narod.ru> writes:
Should I prefix all module names with `xmlboiler.` (where XML 
Boiler is the name of my program). These packages are expected to 
be used internally by my program, not as an exported API (however 
there are some little chances that in the future I will make a 
public API)
Jan 28 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 28, 2019 at 04:59:22PM +0000, Victor Porton via Digitalmars-d-learn
wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler
 is the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are
 some little chances that in the future I will make a public API)


I won't pretend to speak for anyone else, but personally, I don't even
bother with packages until my code has grown past a certain size. It's
just useless cruft and needless complexity for small to medium sized
projects. It's only when you're planning to export a public API, or when
your code has grown past a certain size, that it becomes useful to
segregate the code into different packages.

So IMO you don't need to bother.  You can always refactor the code later
to have a package name when you make a public API.


T

-- 
Famous last words: I wonder what will happen if I do *this*...
Jan 28 2019
parent Johannes Loher <johannesloher fg4f.de> writes:
Am 28.01.19 um 18:29 schrieb H. S. Teoh:

 On Mon, Jan 28, 2019 at 04:59:22PM +0000, Victor Porton via
Digitalmars-d-learn wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler
 is the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are
 some little chances that in the future I will make a public API)


 
 I won't pretend to speak for anyone else, but personally, I don't even
 bother with packages until my code has grown past a certain size. It's
 just useless cruft and needless complexity for small to medium sized
 projects. It's only when you're planning to export a public API, or when
 your code has grown past a certain size, that it becomes useful to
 segregate the code into different packages.
 
 So IMO you don't need to bother.  You can always refactor the code later
 to have a package name when you make a public API.
 
 
 T
 


This is basically the same thing I do: Start with toplevel modules and
reorder them into packages once things get more complicated. Mostly I
only include a top level package named like my project when writing a
project which might be used by other projects (i.e. library code). So
far this has worked very well for me.

If you expect name clashes with other modules you import, prefixing your
own modules with a top level package is a valid solution.
Jan 29 2019
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Mon, 28 Jan 2019 16:59:22 +0000, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler is
 the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are some
 little chances that in the future I will make a public API)


You do you. I put all my source files inside a package unless it's a one-
file project mainly so that I can sort my import directives and have them 
organized nicely. But if you don't want to have to type `xmlboiler` five-
ish times per source file, you can skip it.
Jan 28 2019
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/28/19 11:59 AM, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler is 
 the name of my program). These packages are expected to be used 
 internally by my program, not as an exported API (however there are some 
 little chances that in the future I will make a public API)


I use a package nearly every time because if you don't, you run into 
weird quirks of the language for top-level modules.

You might use a short name, like `xmlb` or something.

-Steve
Jan 28 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:

 On 1/28/19 11:59 AM, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler
 is the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are
 some little chances that in the future I will make a public API)


 
 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.


T

-- 
Старый друг лучше новых двух.
Jan 28 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/28/19 3:16 PM, H. S. Teoh wrote:

 On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:

 On 1/28/19 11:59 AM, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler
 is the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are
 some little chances that in the future I will make a public API)


 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.


I'm trying to remember, but there are definitely conflicts with 
top-level modules that do not happen when packages are involved. Someone 
help me out here...

-Steve
Jan 28 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/28/19 4:57 PM, Steven Schveighoffer wrote:

 On 1/28/19 3:16 PM, H. S. Teoh wrote:

 On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via 
 Digitalmars-d-learn wrote:

 On 1/28/19 11:59 AM, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.` (where XML Boiler
 is the name of my program). These packages are expected to be used
 internally by my program, not as an exported API (however there are
 some little chances that in the future I will make a public API)


 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.


 
 I'm trying to remember, but there are definitely conflicts with 
 top-level modules that do not happen when packages are involved. Someone 
 help me out here...


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.

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.

-Steve
Jan 28 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 30 2019
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 28 January 2019 at 16:59:22 UTC, Victor Porton wrote:

 Should I prefix all module names with `xmlboiler.`


Yes.

All module names should have at least two parts. If you don't, 
you will regret it later when you have to rename or see conflicts 
with other libraries.
Jan 28 2019