Proposal: Restrict class/interface scope to namespace

[NickT1977]

Limit the scope of a class or interface to namespace level.
e.g.
internal namespace class MyClass
or
internal namespace interface MyInterface
These would only be accessible to classes within the same namespace.

Thanks
Nick

[erik-kallen]

I guess that with

These would only be accessible to classes within the same namespace.

you mean

These would only be accessible to classes within the same namespace in the same assembly.

I think this is an excellent idea (I have thought about it myself). For many applications the project is not the optimal granularity for determining visibility

[jnm2]

There's no way to express this in IL, so even if C# annotated it specially and played along, other languages would still see everything as internal. This wouldn't really matter I guess, depending on how you expect it to interact with InternalsVisibleTo.

[erik-kallen]

@jnm2 That's where the "in the same assembly" condition would come in. No annotations would even be required, it would only need to be marked as internal in IL. I wouldn't mind if InternalsVisibleTo exposed these types as well, it is (probably) mainly used for testing and these types could do with tests, too

[CyrusNajmabadi]

Why not just compile this into its own assembly? Then internal will mean just what you want.

[jochenz]

Because it leads to an excessive amount of assemblies.
Also, if you want to PoC software designs, you cannot test this kind of encapsulation/implementation hiding in a single project.
You have to create a bunch of projects to do so, while a folder structure linked to namespaces would be a very elegant solution.

[NickT1977]

@CyrusNajmabadi I could get the same behaviour by using different assemblies and the internal scope but it is very common that in a namespace I will have a set of related a few classes that has just one class with the entry points that I want to expose to the rest of the project (the other classes are just implementation detail). Using assembly's seems like a bit overkill for the amount of times that this occurs and I would prefer not to have potential many assembly's with only a handful of classes in each.

[DavidArno]

... it is very common that in a namespace I will have a set of related a few classes that has just one class with the entry points that I want to expose to the rest of the project ...

Why not make those "implementation details" classes, private nested classes of the entry point class?

[kovianyo]

It is easier to move separate files and to view history of separate files in source control, than having the changes in the same file.

[jochenz]

Because you cannot derive from these. Think of this scenario:

• a repositories folder (using a repositories namespace)
• a private base repository class
• all repository implementations derive from the private base class and are therefore also private to the namespace
• so they can only be accessed through their (internal or public) interface

Seems like a very elegant solution to me.
Once you decide your repositories need to go into a separate assembly, you can do so, since your design guaranteed the decoupling from the start.

[bondsbw]

Here is a related proposal I never ported over here: dotnet/roslyn#8391

To sum it up: separate the logical concept of component from the physical concept of assembly. You can have multiple components in an assembly (components would likely be different namespaces). The internal keyword then follows the logical component.

One major difference with just using assemblies is performance during the build process. Achieving this style of encapsulation would need multiple small assemblies. Building many tiny projects takes much longer than a large monolithic project.

[Pzixel]

@bondsbw in my previous company we had an analyzer for very this purpose that wouldn't allow you to use the type from external namespace. We hade very same issue: one assembly which contains multiple "projects", each in its own namespace. And yet, one simple analyzer that doesn't allow you to add using or use directly type from the other "project".

[MkazemAkhgary]

as long as its internal you shouldn't really care. with correct use of namespaces you can eliminate need of this feature.

with a proper naming and grouping of types in namespaces you will no longer pollute namespaces, please don't get obsessed as long as these types are internal and it wont affect users experience, neither yours.

don't worry to write namespaces with only internal types. when you reference a compiled dll of your class library those namespaces will not show up in intellisense.

https://stackoverflow.com/questions/720647/hiding-namespaces-containing-only-internal-types-in-a-class-library

[bondsbw]

@MkazemAkhgary

as long as its internal you shouldn't really care

One of the goals of the other proposal is dependency management. Today you can use assemblies to enforce decoupling (no cyclic dependencies) and encapsulation (internal); in that proposal, you could use components to do the same, without the need for separate projects/assemblies.

[jochenz]

And it allows a more agile development process. Hide private "internals" in namespaces, so it's easy to refactor them to dedicated assemblies later, if you would feel the need to.
You can do so, since your design with classes scoped privately to namespaces, guaranteed the decoupling from the moment you started developing the software.

[bondsbw]

To be clear, I don't split my code into 1000 projects. I don't think many developers do. The build time isn't worth it, even if you get better decoupling and encapsulation.

But I do segment large projects into many namespaces. Turning those into components would be a huge help for dependency management.

[Pzixel]

@bondsbw I already have given you an answer: write code analyzer, 30 minutes of coding and you're done.

[CyrusNajmabadi]

So what? InternalsVisibleTo is only used for testing anyway,

Fwiw, that's definitely not the case. Ivt is used for more than just testing.

[erik-kallen]

What other valid uses does it have? If I saw that in code I was working on, I would definitely consider it a major smell.

[CyrusNajmabadi]

It was created, and is used, for that normal case of allowing teams to create assembly boundaries that can still share internal data and code.

Roslyn, as an example, uses this extensively. We distribute layered assemblies with many apis (like our Workspace/Features/EditorFeatures/etc. assemblies), but with ivt between them so they can function effectively.

Without ivt we would need all of this integration to be through public apis, which would be completely untenable. Once public we would never be able to change them as that could break 3rd parties.

Ivt effectively allows you to have your pubic apis, with the rules around those, while also having internal apis to a known finite audience that you can then safely change.

This is why ivt exists. Public is too broad, and normal 'internal' is too narrow. Ivt bridges that and is the primary reason is was created (for baby other teams, including the bcl, that needed this).

[erik-kallen]

Your response that the core/compiler teams also realize that the assembly is not a visibility granularity that fits all.

Anyway, even if people really use it, I don't see why it would be a problem that [InternalsVisibleTo()] also means that these "namespace internal" types are also visible to the assembly that has been explicitly granted access to internal types.

[HaloFour]

IVT was necessary as there was nothing in the runtime to support an accessibility between internal and public. Even if analyzers existed as a solution 17 years ago they would not have worked as analyzers cannot enforce that behavior between arbitrary projects, especially those that could be in any language and use any compiler.

What you're looking for is something less accessible than internal, which would not need to be enforced outside of the current project. That's a perfect use case for analyzers and it allows you to solve your problem rather than waiting for the language team to take an interest in this proposal, which in five years has not happened.

[bondsbw]

@Pzixel I understood that. Obviously an analyzer would work. The other proposal was even based on an NDepend "analyzer" that did this years before Roslyn existed.

Including this mechanism within the shipping product standardizes it.

[Pzixel]

@bondsbw then you could just create a nuget package with this analyzer and share it whenever you want :)

Seriously, I don't think we need this feature to be built in the language itself.

[CyrusNajmabadi]

To sum it up: separate the logical concept of component from the physical concept of assembly

The issue i have is this: That's a fine idea, but i don't know why it is tied to a namespace. For example, i may still have a logical component that is spread over a few namespaces. I may do this for my own organizational reasons, or because it makes sense for my public API. Common things may go in my root namespace, with much more specialized stuff in my child namespaces.

It sounds like you'd actually want something totally unrelated to accomplish this. Something like:

component X {
  namespace Y {
    component class Z { } // only visible to others in my same component
  }
}

That said, i think this sort of thing always breaks down. Eventually you have strange venn diagrams of things you want to be visible (i.e. Component A and B should see each other, and B and C shoudl as well, but not A and C). So i think it's sorta worthless in the end.

Today, we have an actual solution throughout the toolchain: Use assemblies, and use InternalsVisibleTo to indicate when components do share between them. You can then merge those assemblies at the end of the day if you don't want to actually ship that way.

This, to me, seems like a good enough solution without having to go spend an enormous effort to yet against try to come up with a componentization model.

[CyrusNajmabadi]

I'm talking about hundreds of components

That would be even better for parallelization. Lots of opportunity there :)

[ChristopherHaws]

I would like to see something like this as well. Here is how I would like to see it done:

namespace RootNamespace.InnerNamespace
{
    private class PrivateClass { }

    protected class ProtectedClass { }
}

namespace RootNamespace
{
    // PrivateClass is not accessible
    // ProtectedClass is not accessible
}

namespace RootNamespace.InnerNamespace
{
    // PrivateClass is accessible
    // ProtectedClass is accessible
}

namespace RootNamespace.InnerNamespace.InnerNamespace2
{
    // PrivateClass is not accessible
    // ProtectedClass is accessible
}

[Pzixel]

@ChristopherHaws this is how it works today, isn't it? 😉

[ChristopherHaws]

@Pzixel No. Currently you can't have private or protected classes directly in namespaces, only in classes.

[MkazemAkhgary]

What you want is "internal". Can you please elaborate more on whats the use of private/protected class in namespace level? @ChristopherHaws

[Joe4evr]

@ChristopherHaws There's no way to express that in the IL: top-level types are either public or private (exposed as ìnternal in C#).

[Logerfo]

@Joe4evr Does this really need to be featured in IL? I mean, if this was just a c# language feature (making namespace level private in IL) that would be enough for me.

[DavidArno]

@Logerfo,

It is possible to mix languages in a single assembly (though VS doesn't currently support this directly). So you'd have the situation where eg a web project containing C# and VB.Net code would have different accessibility rules depending on the language used. Sounds messy.

[Logerfo]

@DavidArno I don't think that types declared with the namespace access modifier should be accessible from other assemblies, even with the same namespace. That being true, your concern is not an issue.

[DavidArno]

@Logerfo,

That's not what I said. You can mix languages in the same assembly, so that C# code would be unable to access types that the VB.Net code, in the same assembly, would be able to access.

[Logerfo]

@DavidArno how's that possible? and if so, why does both csproj and vbproj exist?

[Pzixel]

@Logerfo this produce different assemblies http://msdn.microsoft.com/en-us/library/ms366714.aspx
however, you still can reference C# class from VB, because they got compiled in the same IL.

Using MSBuild and custom task you can force two different languages to be merged in one single assembly. The supplied .targets force the projects to be single language - but there's no runtime or tooling restriction preventing this.

Both the VB and CS compilers can output to modules - the CLR's version of .obj files. Using the assembly linker, you could take the modules from the VB and CS code and produce a single assembly.
https://thomasfreudenberg.com/archive/2006/08/21/mixing-c-and-vb-net-in-one-assembly/

[jnm2]

Plus, everyone is familiar with ILMerge, right?

[honza77]

Did anybody considered something like Haskell or ML style modules? Am not sure how they differ from VB.Net modules.

[Chad077]

The suggested namespace modifier would fill the gap between the current protected and internal modifiers. There is no clean easy workaround for the lack of safe encapsulation at namespace branch (subsystem) level. I don't care for cross-assembly so what equates to "internal namespace" is fine and would be greatly appreciated.

[jochenz]

namespace MyNamespace.SubNamespace;

private class MyClassScopedToMySubNamespace
{
}

would do perfectly fine for me.

[iam3yal]

Like @jochenz I think that it's better and more correct to have a private modifier on the type as opposed to the namespace as it may contain other types that should be visible outside.