Matching Type and namespace names

Topics: C# Language Design
Sep 20, 2014 at 11:47 AM
Often when I need to create some class AAA I also need several classes special for AAA work.

I can declare they as AAA subclasses AAA.B, AAA.C, AAA.X but this is not always suitable (Classes in separate assemblies).


So I want to declare class like subname of class:
namespace NS1
{
    class SomeWindow : Window
    {
        public static void GoRun(){...}
    }
}

...

namespace NS1
{
    class SomeWindow.XYX
    {
        ...
    }

    class SomeWindow.GoRun //class hides superclass static memeber use new 
    {
        ...
    }
}
In SolutionExplorer classes SomeWindow.XYX and SomeWindow.GoRun can be visualized as subnodes of SomeWindow:
  • SomeWindow
    • XYX
    • GoRun
Even is SomeWindows not declared in current project it Just will be empty Node.
namespace NS1
{
 class SomeWindow.XYX.SSS{...} //This is valid too
 class SomeWindow.XYX.RRR{...} //This is valid too
}

// And in short 
namespace NS1.SomeWindow.XYX
{
 class SSS{...} //This is valid too
 class RRR{...} //This is valid too
}
Sep 20, 2014 at 6:02 PM
I don't understand your request at all. Do you have an actual use case?

Nested classes officially belong to a parent class and that parent class cannot span assemblies. That is part of the design of the CLR. You could define a derived class of the parent class in a second assembly and use that to contain more nested classes and access the parent's nested classes depending on the accessibility. Otherwise it looks like all you're asking for is nested namespaces, which C# supports already. But namespaces and classes are not interchangeable in the CLR, even if that class is static and contains no members.
Sep 20, 2014 at 7:58 PM
It all about Compiler not CLR.

if I write:
class Foo
{
   ...
}

namespace Foo
{
      class Bar{}
}
...

var foo = new Foo(); it is about Foo class
var bar = new Foo.Bar(); it is about Bar class inside Foo namespace

This is compile error but does not to be! Class Bar full name is Foo.Bar and namespaces is not exists it is just C# syntax sugar.

So we can write new compiler without this limitation.

And if we have Bar class inside Foo namespace and Bar subclass inside Foo class:


class Foo
{
class Bar{}
}

namespace Foo
{
  class Bar{}
}
...

Than Foo.Bar is ambiguous but for clr it is two different names
one is Foo.Bar - it is about Bar class inside Foo namespace
second is Foo/Bar - it is about Bar subclass inside Foo class

So C# can provide syntax for resolving those collisions.
Sep 21, 2014 at 1:23 AM
JesInc28 wrote:
It all about Compiler not CLR.

if I write:
class Foo
{
   ...
}

namespace Foo
{
      class Bar{}
}
This is already a compiler error due to namespace collision. You can't have a namespace and a class with the same name in the same assembly.
var foo = new Foo(); it is about Foo class
var bar = new Foo.Bar(); it is about Bar class inside Foo namespace
That depends entirely on the namespaces in scope. Both can be legal and both can be ambiguous.
So we can write new compiler without this limitation.

And if we have Bar class inside Foo namespace and Bar subclass inside Foo class:
class Foo
{
   class Bar{}
}

namespace Foo
{
      class Bar{}
}
You haven't explained why. The fact that it might be possible doesn't mean that it should be done. Can you describe an actual use case and not a contrived scenario?
So C# can provide syntax for resolving those collisions.
C# already provides mechanisms for resolving name collisions, aliasing and global namespaces.
Sep 21, 2014 at 6:21 PM
This is already a compiler error due to namespace collision. You can't have a namespace and a class with the same name in the same assembly.
I know and wrote that in post above. But this is limitation of C# not CLR
You haven't explained why. The fact that it might be possible doesn't mean that it should be done. Can you describe an actual use case and not a contrived scenario?
When I have class A that describe one system e.g. SolutionExplorer of VisualStudio I don't want to have all A internals in same namespace so I declare namesapce A_ and put all A internals in it and may be one few A internal classes have their own internals than I need to declare A_.Foo_ namespace and A_.Bar_ namespace for classes of that internals. It working but looks Ugly.

When You write some big system you always have class of that system and many classes that realize that system and it subsystems and helpers specially for system and so on.
Now I can not declare:
namespace MyCompany
{
    class  MyCoolSystem
    {
         ...
    }
}

...

namespace MyCompany.MyCoolSystem
{
    class  SomeSubsystem1
    {
         ...
    }

    ...

    class  SomeSubsystem2
    {
         ...
    }
}
So in namespace MyCompany will be not Garbage but only SystemRoots like MyCompany.MyCoolSystem
C# already provides mechanisms for resolving name collisions, aliasing and global namespaces.
They will not help for resolving IL Foo.Bar vs IL Foo/Bar in C# because in C# it is Foo.Bar and Foo.Bar
Sep 21, 2014 at 6:31 PM
That's the same contrived example, not a use case. There is no reason to organize the classes the way that you're organizing them, nor the way you want to organize them. Nobody else is having this issue and I guarantee that your assemblies are much less complicated than mscorlib or System.
Sep 21, 2014 at 10:52 PM
Halo_Four wrote:
That's the same contrived example, not a use case. There is no reason to organize the classes the way that you're organizing them, nor the way you want to organize them. Nobody else is having this issue and I guarantee that your assemblies are much less complicated than mscorlib or System.
There are many patterns in the CLR where classes are related that solved it using the recommendations. Take a look at the types under System.Data.SqlClient namespace.
Sep 22, 2014 at 1:56 AM
PauloMorgado wrote:
Halo_Four wrote:
That's the same contrived example, not a use case. There is no reason to organize the classes the way that you're organizing them, nor the way you want to organize them. Nobody else is having this issue and I guarantee that your assemblies are much less complicated than mscorlib or System.
There are many patterns in the CLR where classes are related that solved it using the recommendations. Take a look at the types under System.Data.SqlClient namespace.
I see a couple underscore-prefixed internal classes defined in that namespace but none of them appear that they would represent a naming collision if they lacked that underscore. None of them are nested types and SqlClient itself is not a class. This doesn't seem to represent a similar problem, just a scenario where someone decided to throw an underscore in there for some arbitrary reason.
Sep 22, 2014 at 8:33 AM
I meant that all those classes are related and there was no need to have a class and a namespace with the same name.