Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

57%

+2 −1

Q&A What does "namespace" mean?

A namespace is a category of names within which they must all be unique. This also means that names do not need to be unique between namespaces. For example, states of the USA is a different name...

posted 1y ago by Olin Lathrop‭ · edited 1y ago by Olin Lathrop‭

Answer

#2: Post edited by

Olin Lathrop‭ · 2023-12-02T15:09:51Z (about 1 year ago)

Copy Link

Raw

Markdown

A namespace is a category of names within which they must all be unique. This also means that names do not need to be unique between namespaces.
For example, states of the USA is a different namespace from countries of the world. "Georgia" has a completely different meaning in these two namespaces. That also requires that whenever the name "Georgia" is used, the namespace must be specified. In natural languages it is often inferred from context. Consider the two sentences "I visited Florida, Georgia, and South Carolina." and "I visited Turkey, Georgia, and Armenia.". In the first case, I could have visited the US states for Florida and South Carolina and the country of Georgia, but we expect the writer of the sentence to more explicitly tell us of the namespace change if that were the case.
In formal languages, like used for programming computers, we can't allow such ambiguity. We therefore have strict rules for interpreting names of things like variables and subroutines. For example, in many languages variable names are in a separate namespace per subroutine. The variable <tt>count</tt> in subroutine <tt>abc</tt> is different from the variable <tt>count</tt> in subroutine <tt>def</tt>. This is quite useful because the writers of the two subroutines don't have to check every other subroutine to make sure <tt>count</tt> isn't already used somewhere.
~~This concept is also commonly referred to as the "scope" of a name. The scopes of the two <tt>count</tt> variables is only within their respective subroutines.~~
In computer programming, namespaces are usually tree structured. If both subroutines are in the same module, and a variable <tt>count</tt> was defined at module-scope above all the subroutines, then just "<tt>count</tt>" in each subroutine would reference the single variable in the module namespace.
Different languages vary whether it is allowed to then create a <tt>count</tt> additionally in a subroutine, and what an unqualified reference to <tt>count</tt> in that subroutine would mean. In most cases, unqualified references are interpreted as being in the most local namespace. <tt>count</tt> in the subroutine would therefore refer to the local variable, not the module-level variable. It depends on the language how the module-level <tt>count</tt> is specified, and whether that's even possible at all.

A namespace is a category of names within which they must all be unique. This also means that names do not need to be unique between namespaces.
For example, states of the USA is a different namespace from countries of the world. "Georgia" has a completely different meaning in these two namespaces. That also requires that whenever the name "Georgia" is used, the namespace must be specified. In natural languages it is often inferred from context. Consider the two sentences "I visited Florida, Georgia, and South Carolina." and "I visited Turkey, Georgia, and Armenia.". In the first case, I could have visited the US states for Florida and South Carolina and the country of Georgia, but we expect the writer of the sentence to more explicitly tell us of the namespace change if that were the case.
In formal languages, like used for programming computers, we can't allow such ambiguity. We therefore have strict rules for interpreting names of things like variables and subroutines. For example, in many languages variable names are in a separate namespace per subroutine. The variable <code>count</code> in subroutine <code>abc</code> is different from the variable <code>count</code> in subroutine <code>def</code>. This is quite useful because the writers of the two subroutines don't have to check every other subroutine to make sure <code>count</code> isn't already used somewhere.
This concept is also commonly referred to as the "scope" of a name. The scopes of the two <code>count</code> variables is only within their respective subroutines.
In computer programming, namespaces are usually tree structured. If both subroutines are in the same module, and a variable <code>count</code> was defined at module-scope above all the subroutines, then just <code>count</code> in each subroutine would reference the single variable in the module namespace.
Different languages vary whether it is allowed to then create a <code>count</code> additionally in a subroutine, and what an unqualified reference to <code>count</code> in that subroutine would mean. In most cases, unqualified references are interpreted as being in the most local namespace. <code>count</code> in the subroutine would therefore refer to the local variable, not the module-level variable. It depends on the language how the module-level <code>count</code> is specified, and whether that's even possible at all.

#1: Initial revision by

Olin Lathrop‭ · 2023-12-02T15:01:38Z (about 1 year ago)

Copy Link

Raw

Markdown

A namespace is a category of names within which they must all be unique.  This also means that names do not need to be unique between namespaces.

For example, states of the USA is a different namespace from countries of the world.  "Georgia" has a completely different meaning in these two namespaces.  That also requires that whenever the name "Georgia" is used, the namespace must be specified.  In natural languages it is often inferred from context.  Consider the two sentences <i>"I visited Florida, Georgia, and South Carolina."</i> and <i>"I visited Turkey, Georgia, and Armenia."</i>.  In the first case, I <i>could</i> have visited the US states for Florida and South Carolina and the country of Georgia, but we expect the writer of the sentence to more explicitly tell us of the namespace change if that were the case.

In formal languages, like used for programming computers, we can't allow such ambiguity.  We therefore have strict rules for interpreting names of things like variables and subroutines.  For example, in many languages variable names are in a separate namespace per subroutine.  The variable <tt>count</tt> in subroutine <tt>abc</tt> is different from the variable <tt>count</tt> in subroutine <tt>def</tt>.  This is quite useful because the writers of the two subroutines don't have to check every other subroutine to make sure <tt>count</tt> isn't already used somewhere.

This concept is also commonly referred to as the "scope" of a name.  The scopes of the two <tt>count</tt> variables is only within their respective subroutines.

In computer programming, namespaces are usually tree structured.  If both subroutines are in the same module, and a variable <tt>count</tt> was defined at module-scope above all the subroutines, then just "<tt>count</tt>" in each subroutine would reference the single variable in the module namespace.

Different languages vary whether it is allowed to then create a <tt>count</tt> additionally in a subroutine, and what an unqualified reference to <tt>count</tt> in that subroutine would mean.  In most cases, unqualified references are interpreted as being in the most local namespace.  <tt>count</tt> in the subroutine would therefore refer to the local variable, not the module-level variable.  It depends on the language how the module-level <tt>count</tt> is specified, and whether that's even possible at all.

Communities

Post History