How to Remember Namespaces

I often see people using the term “namespace” incorrectly. Even when explanations of what a namespace is are presented, they only go as far as describing its function, neglecting to properly define the name “namespace” itself.

Definition of the Namespace

A namespace is literally the space to which a name belongs. If we were to classify the term namespace, it would be a specification (concept), not a tool.

In namespaces, the higher level is represented as outer and the lower level as inner. In terms of class structure, this corresponds to outer classes and inner classes. In other words, to explain it from a different perspective, it looks like this.

Representation of namespaces from the outer perspective

• Build namespaces (best)
• Define namespaces (to fit many programming language implementations)
• Open namespaces (such as Ruby’s class definition and module definition)
• Create namespaces (such as the pseudo-namespace hack in older JavaScript)
• Declare namespaces (such as the package declaration in Java or the namespace declaration in PHP)

Representation of namespaces from the inner perspective

• Belong to a namespace (best)
• Entering the namespace (This is entirely from an inner perspective, so it might feel out of place depending on the context)
• Be included in the namespace (this is a reasonable explanation if explained objectively).

Incorrect expression

From the definition above, it is clear that the following expressions are incorrect.

• Add/Paste a namespace (the expression “add/paste a space” is grammatically incorrect).
• Use namespaces (not to the point of being completely broken, but treating namespaces as a tool)
• Separate/Cut namespaces (While “Separated by namespaces” is understandable, “separate/cut” can be misleading)

Meaning of “Name” in Namespace

The “names” referred to here can be class names, module names, or package names. What they represent varies depending on the language that implements namespaces.

For example, in Ruby, it refers to constant names. In Ruby, class names (module names) are also constants, so outer refers to class name constants, and inner includes both general constants and class name constants. Since general constants cannot be outer, a structure is created where class name constants can be nested, but general constants cannot.

An easy-to-understand metaphor

Belonging to a namespace means that inner moves to a town called outer, and inner is included in outer‘s address book. Problems arise if an entity claims an address in another town without actually being in it (this example is easily illustrated by Ruby’s constants 1).

Alternatively, a tenant named inner would enter into a lease agreement with a multi-tenant building called outer, and inner would occupy a floor within that building. As a result, inner‘s address would be “inner tenant inside the outer building”.

1. Ruby constants have a reference path that combines a lexical namespace and inheritance. When moving and referencing (physical nesting), you can reference the constants of the outer namespace, but when calling out the address from outside (adding a namespace prefix), you cannot reference the constants of the outer namespace. ↩