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

Status : 

  Other<br /><br />
		This item had a custom resolution.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 602150 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 9/20/2010 3:49:36 AM
Access Restriction Public

Description

Access modifiers in .NET were designed with the idea that you can trust your co-workers to know how the code works and hence not slip up and introduce a bug.

This idea is flawed though. Software development is so complicated that an experienced programmer knows not to even trust him/herself! For this reason, experienced programmers prefer to write code which, by design, cannot be broken through accidental misuse. .NET provides the tools to do this when only one class is involved, but the moment a programmer attempts to create a bullet-proof set of two or three interacting classes, this breaks down.

The .NET-intended approach to this is to mark the shared members as "internal", which allows the classes to interact with each others' internals. Unfortunately this also allows _every other class in the assembly_ to mess with the internals, be it by accident or intentionally.

SUGGESTION:

Introduce a "nested" access modifier. When used on a member, this modifier allows access from any code contained in the outermost nested type. A top-level type (not nested in any other types) cannot have this modifier specified.

Additionally, to allow several top-level types to have mutual access to each other's members, introduce a custom attribute, "NestedVisibleTo" or similar, which can be specified on a _type_ only, and specifies one or more types. All the listed types may then access this type's "nested"-modifier members, in addition to the usual ones, but not, for example, the "private" ones.

Types nested one level deep should still be allowed to have this access modifier specified, because this would allow additional access when used in conjunction with "NestedVisibleTo".
Sign in to post a comment.
Posted by Microsoft on 1/20/2011 at 2:49 PM
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
Posted by Roman.St on 11/24/2010 at 5:30 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.
Posted by kirsche40 on 10/20/2010 at 3:38 AM
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?
Posted by Microsoft on 9/20/2010 at 4:36 AM

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)