<p>Different languages have different naming conventions for their modules. For example, Java-family languages usually use full reverse-domain-name names for packages (ie <code>com.example.examplemodule</code>). Python, however, lets you name your modules whatever you want. What are the pros and cons of these methods, and are there any other ones?</p>

<imports><style>
What are good specifications for naming packages/modules in a language?
CC BY-SA 4.0
2023-05-21T16:29:42.750Z
@seggan I was going to your comment as an example of why https://languagedesign.stackexchange.com/questions/888/how-can-isolated-focus-on-syntax-be-counterproductive-in-the-earlier-stages-of-a shouldn't be closed only to do find this site is apparentl more like Stack Overflow after all.
Bruce Adams
CC BY-SA 4.0
2023-05-21T16:47:16.563Z
Actually I've raised this on meta - https://languagedesign.meta.stackexchange.com/questions/219/are-we-more-like-world-building/220#220
Bruce Adams
CC BY-SA 4.0
2023-05-21T19:37:37.550Z
@BruceAdams the other question has been reopened and yours is on track for reopening too
Seggan
CC BY-SA 4.0
2023-05-22T00:28:52.973Z
from what I'm seeing from the answers. naming itself is really only important if you value consistency. Everything else that matters is beneath the surface, and really has less to do with naming and more to do with broader things like package management and usage and name/module resolution methods.
starball
CC BY-SA 4.0
2023-05-17T13:04:21.883Z
Slightly related: https://languagedesign.stackexchange.com/q/167/34
Nike Dattani
CC BY-SA 4.0
2023-05-17T13:26:29.483Z
On regular stack overflow this would risk being closed as opinion based and/or too broad. You might want to try and constrain the question more.
Bruce Adams
CC BY-SA 4.0
2023-05-17T14:50:48.333Z
@BruceAdams this isn’t Stack Overflow, we are more like Worldbuilding or UX in that respect (in fact, we are UX for the people who build UX :P)
Seggan
<p>The most common schemes seen are <code>foo.bar.baz</code> and <code>foo::bar::baz</code> (I don't think I need to mention the PHP scheme).</p>
<ul>
<li><p>Hierarchal names like this makes it easy to organize libraries in sub modules, e.g. <code>my_lib.io.foo</code> <code>my_lib.net.bar</code>.</p>
</li>
<li><p>It allows recursive inclusion of sub modules, e.g &quot;import my_lib.*&quot;.</p>
</li>
<li><p>Code completion etc can be made more relevant, e.g. <code>my_lib.&lt;code complete to find sub modules&gt;</code> or <code>my_lib.io.&lt;code complete finds io functions&gt;</code></p>
</li>
<li><p>Fairly unexplored is the idea of path shortening, where the compiler could choose to require only a subset of a namespace path, so for example using <code>net.bar</code> to refer to <code>my_lib.net.bar</code> if it is unambiguous (C3 uses this)</p>
</li>
<li><p>A separator also makes the name a bit less ambiguous. Compare <code>net.address.File</code> and <code>net_address.File</code>.</p>
</li>
</ul>

CC BY-SA 4.0
2023-05-17T14:08:05.140Z
2023-05-17T14:08:05.140Z
Nuoji
CC BY-SA 4.0
2023-07-01T03:34:30.347Z
I think the question's more about the names of packages/libraries as a whole rather than modules/components of them
rydwolf
# What are good specifications for naming packages/modules in a language?
Posted by: username_0 on 2023-05-17
Different languages have different naming conventions for their modules. For example, Java-family languages usually use full reverse-domain-name names for packages (ie `com.example.examplemodule`). Python, however, lets you name your modules whatever you want. What are the pros and cons of these methods, and are there any other ones?
**Tags:** imports style
> **Comments:**
> **username_4**: Slightly related: https://languagedesign.stackexchange.com/q/167/34  
> **username_1**: On regular stack overflow this would risk being closed as opinion based and/or too broad. You might want to try and constrain the question more.  
> **username_2**: @BruceAdams this isn’t Stack Overflow, we are more like Worldbuilding or UX in that respect (in fact, we are UX for the people who build UX :P)  
> **username_1**: @seggan I was going to your comment as an example of why https://languagedesign.stackexchange.com/questions/888/how-can-isolated-focus-on-syntax-be-counterproductive-in-the-earlier-stages-of-a shouldn't be closed only to do find this site is apparentl more like Stack Overflow after all.  
> **username_1**: Actually I've raised this on meta - https://languagedesign.meta.stackexchange.com/questions/219/are-we-more-like-world-building/220#220  
> **username_2**: @BruceAdams the other question has been reopened and yours is on track for reopening too  
> **username_3**: from what I'm seeing from the answers. naming itself is really only important if you value consistency. Everything else that matters is beneath the surface, and really has less to do with naming and more to do with broader things like package management and usage and name/module resolution methods.  
---
## 1 answers
### Answer by username_5 on 2023-05-17. Score: 3
The most common schemes seen are `foo.bar.baz` and `foo::bar::baz` (I don't think I need to mention the PHP scheme).

* Hierarchal names like this makes it easy to organize libraries in sub modules, e.g. `my_lib.io.foo` `my_lib.net.bar`.
* It allows recursive inclusion of sub modules, e.g "import my\_lib.\*".
* Code completion etc can be made more relevant, e.g. `my_lib. or my_lib.io.`
* Fairly unexplored is the idea of path shortening, where the compiler could choose to require only a subset of a namespace path, so for example using `net.bar` to refer to `my_lib.net.bar` if it is unambiguous (C3 uses this)
* A separator also makes the name a bit less ambiguous. Compare `net.address.File` and `net_address.File`.
> **Comments:**
> **username_6** (2023-07-01): I think the question's more about the names of packages/libraries as a whole rather than modules/components of them  
---
