<p>In JavaScript, accessing items from a module is done using <code>.</code>, e.g. <code>moduleBar.moduleFoo.functionFoo</code>, which looks exactly the same as accessing a property of an object, e.g. <code>objectFoo.propertyFoo</code>.</p>
<p>In Rust, you use <code>::</code> to navigate through modules, such as <code>module_bar::module_foo::function_foo</code>, but use <code>.</code> for accessing a property of a structure, e.g. <code>structure_foo.property_foo</code>.</p>
<p>What's the benefit of Rust's approach? The obvious thing is that it's easier to tell at a glance what <code>a</code> is when you write <code>a::b</code> or <code>a.b</code>. If this is the only reason (or one of the bigger reasons), then why does this matter in practice so much that it justifies introducing a token to the language, since &quot;structure vs. module&quot; is really the only difference you can infer purely based on the token used to &quot;drill through&quot; an entity (e.g. you can't even tell if <code>b</code> is a module again, or a function, or a property (let alone its type) -- which is arguably a piece of information much more commonly required to be inferred as quickly as possible when reading code).</p>

<syntax><properties><modules>
What's the benefit of using different tokens for accessing nested namespaces/modules versus properties?
CC BY-SA 4.0
2023-11-26T18:33:30.043Z
For more languages on both sides: C# uses `.` for namespaces, while C++ (like Rust) uses `::`.
Bbrk24
CC BY-SA 4.0
2023-11-26T19:06:00.583Z
In ECMAScript, the answer to almost every question is: because history. Modules existed as a design pattern in ECMAScript long before they became a language feature. They were implemented as objects with properties, which of course are dereferenced with `.`. So, when modules became a language feature, they retained this for backwards compatibility. In fact, modules still behave very much like objects.
Jörg W Mittag
CC BY-SA 4.0
2023-11-27T07:50:12.300Z
In JS you never navigate *through modules*. The closest you can get to `moduleBar.moduleFoo.functionFoo` is if `moduleBar` *reexports* `moduleFoo`, however, that is the same as exposing it as a property. There is no meaningful difference, and ends up resolved as property navigation anyway. Since a module reexporting another is not special. It just has a property that points to its export. `export moduleBar from "./moduleBar"` can be swapped for `export cost moduleBar = /* ... */` and the result is the same on the consuming side.
VLAZ
<p>The reasons for different lexical and structural choices are going to vary from language to language, as are uses terms like &quot;module&quot;, &quot;package&quot;, &quot;namespace&quot;, and so on, but a key distinction between module access and member access is often that module access is <em>static</em>: <code>a::b</code> definitively statically resolves to an element of that module. It's not so much about knowing that the thing on the left is a module as knowing that the lookup is manifest and that this specific entity is referenced. This <em>can</em> ease static analysis tooling and make local analysis by the programmer simpler, but it's not necessarily an essential distinction.</p>
<p>In Java, which uses <code>.</code> for all navigation, <code>java.lang.String.format(&quot;&quot;)</code> could be calling <code>format</code> on the <code>String</code> class inside the <code>java.lang</code> package — or it could be a call chain starting with the <code>java</code> field of a superclass, and there's no <em>local</em> way to tell which is which. You have to do inheritance resolution to know which is happening. On the other hand, the compiler will be doing that resolution anyway, and the <code>::</code> token was left free for method references later.</p>
<p>For your example of JavaScript, the distinction is a little different: JavaScript <em>modules</em> don't actually themselves have any meaningful existence, but an <code>import</code> statement can bind some exported declarations <em>into an object</em>. That object is first-class and you can do anything you could with any other object to it, including pass it as an argument, alias it, introspect it, and dereference members of it. This is a genuine semantic difference from a static module system, including Java's; the ability to <code>export default</code> a function, which then needs to act like a function, is also a novelty. The module system was also retrofitted into the language, to replace various proto-module systems that of necessity used objects, so easing the transition is a factor — although I'm not sure they'd do it any differently regardless.</p>
<p>Not every language draws this distinction, or has the sort of module system where the question comes up. It's clearly not essential, but languages do make lots of design choices to match their priorities that aren't essential.</p>

CC BY-SA 4.0
2023-11-26T19:14:03.547Z
2023-11-26T19:14:03.547Z
Michael Homer
# What's the benefit of using different tokens for accessing nested namespaces/modules versus properties?
Posted by: username_0 on 2023-11-26
In JavaScript, accessing items from a module is done using `.`, e.g. `moduleBar.moduleFoo.functionFoo`, which looks exactly the same as accessing a property of an object, e.g. `objectFoo.propertyFoo`.

In Rust, you use `::` to navigate through modules, such as `module_bar::module_foo::function_foo`, but use `.` for accessing a property of a structure, e.g. `structure_foo.property_foo`.

What's the benefit of Rust's approach? The obvious thing is that it's easier to tell at a glance what `a` is when you write `a::b` or `a.b`. If this is the only reason (or one of the bigger reasons), then why does this matter in practice so much that it justifies introducing a token to the language, since "structure vs. module" is really the only difference you can infer purely based on the token used to "drill through" an entity (e.g. you can't even tell if `b` is a module again, or a function, or a property (let alone its type) -- which is arguably a piece of information much more commonly required to be inferred as quickly as possible when reading code).
**Tags:** syntax properties modules
> **Comments:**
> **username_1**: For more languages on both sides: C# uses `.` for namespaces, while C++ (like Rust) uses `::`.  
> **username_2**: In ECMAScript, the answer to almost every question is: because history. Modules existed as a design pattern in ECMAScript long before they became a language feature. They were implemented as objects with properties, which of course are dereferenced with `.`. So, when modules became a language feature, they retained this for backwards compatibility. In fact, modules still behave very much like objects.  
> **username_3**: In JS you never navigate *through modules*. The closest you can get to `moduleBar.moduleFoo.functionFoo` is if `moduleBar` *reexports* `moduleFoo`, however, that is the same as exposing it as a property. There is no meaningful difference, and ends up resolved as property navigation anyway. Since a module reexporting another is not special. It just has a property that points to its export. `export moduleBar from "./moduleBar"` can be swapped for `export cost moduleBar = /* ... */` and the result is the same on the consuming side.  
---
## 1 answers
### Answer by username_4 on 2023-11-26. Score: 3 | Accepted answer
The reasons for different lexical and structural choices are going to vary from language to language, as are uses terms like "module", "package", "namespace", and so on, but a key distinction between module access and member access is often that module access is *static*: `a::b` definitively statically resolves to an element of that module. It's not so much about knowing that the thing on the left is a module as knowing that the lookup is manifest and that this specific entity is referenced. This *can* ease static analysis tooling and make local analysis by the programmer simpler, but it's not necessarily an essential distinction.

In Java, which uses `.` for all navigation, `java.lang.String.format("")` could be calling `format` on the `String` class inside the `java.lang` package — or it could be a call chain starting with the `java` field of a superclass, and there's no *local* way to tell which is which. You have to do inheritance resolution to know which is happening. On the other hand, the compiler will be doing that resolution anyway, and the `::` token was left free for method references later.

For your example of JavaScript, the distinction is a little different: JavaScript *modules* don't actually themselves have any meaningful existence, but an `import` statement can bind some exported declarations *into an object*. That object is first-class and you can do anything you could with any other object to it, including pass it as an argument, alias it, introspect it, and dereference members of it. This is a genuine semantic difference from a static module system, including Java's; the ability to `export default` a function, which then needs to act like a function, is also a novelty. The module system was also retrofitted into the language, to replace various proto-module systems that of necessity used objects, so easing the transition is a factor — although I'm not sure they'd do it any differently regardless.

Not every language draws this distinction, or has the sort of module system where the question comes up. It's clearly not essential, but languages do make lots of design choices to match their priorities that aren't essential.
---
