Namespace inside class

[rikimaru0345]

Description

I want to be able to easily put stuff into its own namespaces inside a class.

Use Cases

1. Experimental or advanced features
   ...could be "hidden" behind an additional .Experimental so it doesn't pollute the original namespace with many things that might end up being scrapped. It also clearly signals that those things are not intended for production.

2. Better segmentation
   We already have partial classes for some rare cases where its unavoidable (code-generation tools; or large classes that simply cannot be split up for some reason).
   Now imagine how clean some code/intellisense-lists could be if we could also put things into categories like that.
   For example: many hardware emulators have pretty intricate code with some huge classes and breaking them up is not really feasible.
   Most of the time each part of a partial class only references things in its own file/part and rarely needs to access the members of the other implementations.
   Instead of getting many irrelevant things listed in intellisense it would only show the local "scope".

How it's done right now

public class AwesomeThing
{
    public AwesomeThing()
    {
       Experimental = new ExperimentalFeatures(this); // we even *have to* use an explicit constructor here because directly initializing 'Experimental' would give us something like 'this is not valid here'
    }

    public void CommonlyUsedMethod() { }

    private SomeCoolNewExperimentalThing() {} // private version here

    public ExperimentalFeatures Experimental { get; }
    public struct ExperimentalFeatures
    {
         readonly AwesomeThing _obj;
         // init _obj from ctor here

         // public wrapper for the private method:
         public void SomeCoolNewExperimentalThing() => _obj.SomeCoolNewExperimentalThing();
    }
}

What I want to be able to type

public class AwesomeThing
{
    public void CommonlyUsedMethod() { }

    namespace ExperimentalFeatures
    {
          public void SomeCoolNewExperimentalThing() { }
    }
}

Implementation

There are two options:

1. Syntax Sugar
   Auto generate the wrapper struct that we'd normally write ourselves.
   Advantage: Since all it does is generating what's already possible there can't be any problems with it.
   Disadvantage: Since declaring a struct-field in a type pretty much inlines the fields into the type, the type would still have a completely unneccesary reference to itself.
   (yes, I know, in C# and IL the struct still exists, I'm talking about how it looks in memory when the process is running)

2. Make namespace part of the method-name
   ... which means that there's no hidden type and SomeCoolNewExperimentalThing would be a direct member of AwesomeThing.
   However the name of the method would literally be ExperimenalFeatures.SomeCoolNewExperimentalThing.
   Advantage: No hidden field!
   Disadvantage: Is it even possible? Hopefully it wouldn't require any runtime changes.
   Maybe the compiler can somehow work some of its witch-craft like it is already done for enumerators, async, and value tuples. 🤣

Potential problems:

Could be pretty wonky with reflection, maybe?
Actually, FindMethod etc should not really have any trouble with that.
But what about the runtime? Surely there's some code that looks up methods by name, but I doubt that anything like methodName.Split('.') is done (except probably in some badly written user-code)

[CyrusNajmabadi]

Why not just use a nested class for this?

[rikimaru0345]

@CyrusNajmabadi

Why not just use a nested class for this?

Uhh, I'm not sure I'm following.
How would that be any different from the struct approach?

[franchyd]

How would you expect to call these methods?

[rikimaru0345]

@DanFTRX

How would you expect to call these methods?

The How it's done right now example shows it:

public struct ExperimentalFeatures
    {
         readonly AwesomeThing _obj;
         // init _obj from ctor here

         // public wrapper for the private method:
         public void SomeCoolNewExperimentalThing() => _obj.SomeCoolNewExperimentalThing();
    }

The struct can see private members of the parent type.
And it has a reference to it as well, so calling it is no problem, try it :)

[rikimaru0345]

@DanFTRX
Oh, maybe I misunderstood your comment.
You probably meant how it would look for the "outside" caller...

I'd expect it to work exactly like if you'd do it in the struct solution:
myAwesomeThing.Experimental.SomeCoolNewExperimentalThing()

[john-h-k]

So just the same as a nested static class in function?

But also, this is inherently against how namespaces normally work. You seem to have a method directly in a namespace there - that's not legal C#. You'd have to have a nested class/struct inside, like this

class Thing
{
    public void Blah() {}
    namespace Foo
    {
        public static class Bar
        {
            public static void Blah2() {}
        }
     }
}

This would have to be called as such
Thing.Foo.Bar.Blah2(). Much easier to just use a single layer of nesting and remove the namespace, as such
Thing.Bar.Blah2()

[BhaaLseN]

Since SomeCoolNewExperimentalThing is public, why not use an extension method?

public class AwesomeThing
{
    public void CommonlyUsedMethod() { }
}
namespace Experimental
{
   public static class AwesomeThingExtensions
   {
      public void SomeCoolNewExperimentalThing(this AwesomeThing @this) { }
   }
}

You'd only get it to show up if you actually do using YourNamespace.Experimental. You can't do non-public or virtual/abstract stuff like that; but considering it is experimental you might not want that anyways.

[Austin-bryan]

You could've made the code shorter by using expression body members. You also removed the constructor you would likely have anyways in the "after" portion. What I'm getting at is that you've skewed this in a way to prove a point.

Regardless, this is literally the point of nested classes, is it not?

[Austin-bryan]

Going off of what @johnkellyoxford said

class Thing
{
    public void Blah() {}

    namespace Foo
    {
        public static class Bar
        {
            public static void Blah2() {}
        }
     }
}

Would have to be the final code, so why not just

class Thing
{
    public void Blah() {}

    public static class Bar
    {
        public static void Blah2() {}
    } 
}

Cut out the middle man?

[rikimaru0345]

How does Blah2 call any instance method on Thing?

That's not what the original code does at all.

[franchyd]

I think the percieved problem rikimaru wants to solve is that (s)he wants a way to group instance methods, possibly also grouping them in IDE auto-completes
This can be nominally done in the current language in a couple ways

• Prefixing method names. Caveat: Messy naming, would require IDE extensions for autocomplete behavior changes
• Split method groups into nested types.
• Extension methods. Caveat: Arguably does not solve problem. No private member access, will force most members out of the private scope.
• Explicit interfaces

[Edited: Updated list to reflect a few replies]

[HaloFour]

You can use a nested type and an instance property to emulate this kind of grouping:

https://sharplab.io/#v2:D4AQDABCCMDcCwAoJIDMUBMEBiB7XEA3khKRAA4BOAlgG4CGALgKYTUB2jEA+gM6NNmCRGQgkyaHPgAUHLv0EBKIuNGk+AlhAC8EBS2GiAvqrEiJ6ORADKuALbMAguWqzOEAB7Li5tVADsnhAA1Dz6QqYmvmaikgCiHuTMNA6c9AA2eAQJSSnMaek6AHwQ7MwA7hA5ydSpApkyjAAW1LyKhmSmkvyUAK4AxlzVeQVZKtGiVHSCEJTM9AAmuOzpAJ5SBNwcCuz9EROdB6TxiTV1GVnSY9sCu8zepn7qN/R3OmzsO3sdflFPMU9JFZbA5hrV8vVnK4rF5xv9YoEPCEeC87gA6DSCH5qP5kKJRFDoEBYADCcIsUAALBAALJXfAQABm+AeRw+XCRumZuDRIKcLmk0AwqHajzIVnWXPwaLB53SvPszFlEIyUOklIArAA2UXRfFAA=

That gives you the good naming and access to the private state of the parent class:

int x = foo.SomeApi(123);
int y = foo.Experimental.SomeExperimentalApi(456);

[theunrepentantgeek]

Seeing the list by @DanFTRX triggered a brainwave ... what about using an interface?

public class AwesomeThing : AwesomeThing.IExperimentalFeatures
{
    public void CommonlyUsedMethod() { }

    void IExperimentalFeatures.SomeCoolNewExperimentalThing() { }
    
	public IExperimentalFeatures ExperimentalFeatures => this;

    public interface IExperimentalFeatures
    {
          void SomeCoolNewExperimentalThing();
    }
}

All of the methods are implemented directly on AwesomeThing, and therefore have access to private & protected members.

All experimental methods are publicly available by accessing .Experimental, just as proposed.

[rikimaru0345]

@HaloFour
Using an computed-property to fix the issue of having to create the struct is a pretty good idea. That simplifies the original code a lot. It doesn't cost any performance since we're still dealing with a struct. Nice!

@theunrepentantgeek
Good idea! That saves a little more typing work even!

You guys suggested some awesome improvements, I'll use them.