1

I know C# supports namespace nestings, as does C++, which both allow code that looks like this...

namespace A {
    namespace B {
        ...
    }
}

Coming from a C++ background and diving into the C# world I've been meditating upon what appears as a hierarchical nesting of components via all the using directives that must be issued to exploit .NET, eg

using System.Collections;
using System.Collections.Generic;

I'm sure Microsoft intended and designed these libraries to be logically hierarchically organized, but without the aid of seeing the source I cannot verify if System.Collections.Generic has Generic as a nested namespace of Collections, but I assume it is, and that it was accomplished with namespace nestings like seen with A and B. Now once I start cooking up things in my own source and declaring code that looks like this

namespace C.D {
    ...
}

what exactly am I achieving here with respect to a hierarchy? Am I introducing to the code a singular namespace identifier "C.D" where the '.' is simply a friendly means of suggesting a hierarchy that may or may not exist depending upon the code structure or am I implicitly declaring two namespaces "C" and "D" with D nested within C? I've come across this question while cooking up a DevelopmentApplications namespace to our C# codebase that is meant to strictly contain all development tools used to augment our software to aid in its development. In those tools I've never declared a standalone enclosing namespace DevelopmentApplications (which is something I would HAVE to do in C++)...

namespace DevelopmentApplications
{
   ...
}

...but instead always create applications that go like

namespace DevelopmentApplications.MyDevelopmentApp
{
   ...
}

I know this area is a cause of confusion for some because of the following question where the author is struggling to understand the relationship between Foo.Bar.Baz and Foo.Bar. There's also an inverse question of a C# developer entering C++ land that gives some insight into this issue.

I suppose another way to state the question is that in C++ using the '::' operator to fully qualify a type I know guarantees that the code that type was declared in is nested deep in some namespace hierarchy. But in C# using the '.' operator to fully qualify some type must that type also exist in some deeply nested namespace hierarchy? I'm assuming here that C#'s use of a namespace like A.B.C does not necessarily require a hierarchical relationship between A B and C or that A B or C even exist as individual namespaces.

If someone can find or knows the relevant language specification regarding this syntax I'd love to read it.

Community
  • 1
  • 1
jxramos
  • 7,356
  • 6
  • 57
  • 105
  • 1
    By way of avoiding a lot of explanation, have you already familiarized yourself with the background on C# namespaces here? http://msdn.microsoft.com/en-us/library/z2kcy19k.aspx – Robert Harvey Dec 16 '14 at 21:40
  • 1
    You *can* see source, though http://referencesource.microsoft.com/. – Preston Guillot Dec 16 '14 at 21:45

2 Answers2

7

Section 9.2 of the C# 4.0 specs states:

The qualified-identifier of a namespace-declaration may be a single identifier or a sequence of identifiers separated by “.” tokens. The latter form permits a program to define a nested namespace without lexically nesting several namespace declarations. For example,

namespace N1.N2
{
  class A {}
  class B {}
}

is semantically equivalent to

namespace N1
{
  namespace N2
  {
      class A {}
      class B {}
  }
}

You state:

I'm assuming here that C#'s use of a namespace like A.B.C does not necessarily require a hierarchical relationship between A B and C or that A B or C even exist as individual namespaces.

That assumption is false. The namespace A.B.C necessarily involves namespace A in the global namespace, namespace B within namespace A, and namespace C in namespace B.

Servy
  • 202,030
  • 26
  • 332
  • 449
  • Great example to indicate the equivalence of the two namespace declarations. So that syntax does implicitly bring about A's existence, and it does so to the global namespace. I was going to edit my question part about "singular namespace identifier" to be stated in terms of the global namespace. I actually found the exact portion of the spec which states what you state, 9.2 Namespace declarations – jxramos Dec 16 '14 at 22:22
  • That section is worth exposing here: The qualified-identifier of a namespace-declaration may be a single identifier or a sequence of identifiers separated by “.” tokens. The latter form permits a program to define a nested namespace without lexically nesting several namespace declarations. That part about "without lexically nesting several namespace declarations" really makes my link to Adam Naylor's question and his observation about the lexical pain of nested namespaces in C++ totally keen and for me to greater appreciate C#! – jxramos Dec 16 '14 at 22:29
  • @jxramos Sure thing; I've edited the post to include that quote and I just used it's example since we're doing that much. – Servy Dec 16 '14 at 22:36
  • Here's a [restatement](http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf) of the above that probably closest maps to someone with a C++ mindset who needs to interpret these compound namespace declarations in C#. It's a shorthand! 8.12 Namespaces and assemblies Namespaces can nest, and the declaration "namespace CSharp.Introduction {…}" is shorthand for two levels of namespace nesting "namespace CSharp { namespace Introduction {…} }" – jxramos Dec 16 '14 at 23:09
3

Some facts about namespaces in C#:

  1. They are collective. You can declare a namespace in several different source files, and the compiler will treat them all as the same namespace.

  2. You can nest namespaces inside each other, but it's much more common to simply declare the nested namespace in another source file.

  3. There is a global namespace, accessible to every class as global::

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501