Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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 5mo ago by Olin Lathrop‭  ·  edited 5mo ago by Olin Lathrop‭

Answer
#2: Post edited by user avatar Olin Lathrop‭ · 2023-12-02T15:09:51Z (5 months ago)
  • 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.
  • 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 <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 user avatar Olin Lathrop‭ · 2023-12-02T15:01:38Z (5 months ago)
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.