A practical new access modifier for .NET to aid in developing bullet-proof code by Roman.St

Thanks for your proposal.

I agree that this is a relevant concern. I've seen a number of proposals trying to grapple with some notion of "class set accessibility." The complication of course is that, unlike existing accessibilities, there is not already a natural group (everyone, assembly, derived classes, single class) to tie it to, so even with another accessibility modifier you still also need syntax (or something) to define the group.

There are several ways to slice it. I haven't seen a proposal that is obviously right, but I think the problem is relevant, and I will take this up with the design team.

Thanks again,

Mads Torgersen, C# Language PM

Yes, this kind of access modifier is mandatory in many real-life, well-designed class sets. Mandatory in the same way "private" is mandatory: you can actually write all the same code without it, but it's a lot harder to produce reliable code without it in the face of human fallibility.

Let's consider a simple yet real example: System.Text.RegularExpressions.Capture. This class only has an internal constructor. Why internal? Because you and I are not supposed to instantiate it; we're supposed to consume one that is instantiated for us by the Regex subsystem. So far so good.

But how many classes actually instantiate it? Why, just *one*: CaptureCollection. And yet, the constructor is available for the entire System.dll assembly to call. This assembly comprises around 720 files - and a quarter of a million lines of code - almost all of which have absolutely nothing to do with the Regex subsystem. And yet all that code happens to be able to instantiate a Capture, just because one SINGLE other class needed to do so.

Of course someone who works on System.dll is certainly rather unlikely to mess up and instantiate a Capture in error, let alone cause a bug as a result. But translate this to a company that has a high employee turnover coupled with some unrealistic deadlines, and the chances of programmers abusing internal members (ACCIDENTALLY and without realising!) shoot through the roof. And the problem is that no matter how hard you try, when faced with Capture-like coupling between several classes, you will end up having to open up your "privates" to the entire assembly for potential slip-ups.

The sentiment that I only "need" this because my OO design is broken comes up from time to time. I think it stems from the naive idea that everything that one might ever want to encapsulate can be encapsulated in a single class. This is simply not so. The world is complex enough that some things can only be encapsulated by a *set* of classes. To maintain proper encapsulation in this cases we really need the ability to restrict access to a specified set of classes. We need something that does for class sets what "private" does for single classes.

This idea sounds like an improved version of friend-modifier from C++. If you need such modifiers I think your OO-Design is broken. Can you give any example where this friend modifier is a mandatory feature?

Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)