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)

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*...

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.

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

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

-- 
Старый друг лучше новых двух.

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.

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

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

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.

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.