In the next version C# there will be a feature with a name/keyword you will probably hate.
The thread on CodePlex is even named “private protected is an abomination.”
This is the story of that name and what you can do to help get the best possible name.
The feature and why we don’t already have it
C# has a feature called protected internal. Protected internal means that the member is available to any code in the same assembly (internal) and is also available to code in any derived class (protected). In the MSIL (Intermediate Language), this is displayed as famorassem (family or assembly).
MSIL also supports famandassem (family and assembly) which allows access only from code that is in a derived class that is also in the current assembly.
Previously, every time the team has considered adding this feature in C#, they’ve decided against it because no one could think of a good name.
For the next version of C#, the team decided to implement this feature, regardless of whether they could come up with a suitable name. The initial proposal by the team was “private protected.” Everyone seems to hate that name.
One of the great things about this point in language design is that the process is open. It continues to be open to insider’s like MVPs a bit earlier – which reduces chaos in the public – but the conversation is public while there’s still room for change..
In this case, the team decided on a name (private protected) and the outcry caused the issue to be reopened. That was great, because it allowed a lot of discussion. It seems clear that there is no obvious choice.
So the team took all the suggestions and made a survey. Lucian was conservative with the possible joke keywords – if it was possible that someone intended it seriously, it’s in the survey.
How you can help
Go take the survey! You get five votes, so it’s OK to not be a bit uncertain.
If you hate them all, which one annoys you least?
Do you think we need a variation of the IL name familyorassembly?
Do you think we need to include the names internal and/or protected?
Will people confuse and English usage and bit operation?
Will people confuse whether the specified scope is the access or restriction (inclusion or exclusion)?
Should the tradition of all lower case in C# be broken?
Do we need a new keyword?
Is there value in paralleling VB?
Note: In the VB language design meeting on this topic (VM LDM 2014-03-12), we chose to add two new keywords "ProtectedAndFriend" and "ProtectedOrFriend", as exact transliterations of the CLI keywords. This is easier in VB than in C# because of VB’s tradition of compound keywords and capitalizations, e.g. MustInherit, MustOverride. Lucian Wischik [[ If C# parallels, obviously Friend -> internal ]]
I don’t think there’s a promise that the elected name will be the one chosen, but the top chosen names will weigh heavily in the decision.
Go vote, and along the way, some of the suggestions are likely to bring a smile to your face.
Should the feature even be included
There are two arguments against doing the feature. On this, I’ll give my opinion.
If you can’t name a thing, you don’t understand it. Understand it before including it.
This was a good argument the first time the feature came up. Maybe even the second or third or fourth or fifth. But it’s been nearly fifteen years. It’s a good feature and we aren’t going to find a name that no one hates. Just include it with whatever name.
Restricting the use of protected to the current assembly breaks basic OOP principles
OK, my first response is “huh?”
One of the core tenets of OOP is encapsulation. This generally means making a specific class a black box. There’s always been a balance between encapsulation and inheritance – inheritance breaks through the encapsulation on one boundary (API) while public use breaks through it on another.
Inheritance is a tool for reusing code. This requires refactoring code into different classes in the hierarchy and these classes must communicate internal details to each other. Within the assembly boundary, inheritance is a tool for reuse – to be altered whenever it’s convenient for the programmer.
The set of protected methods that are visible outside the assembly is a public API for the hierarchy. This exposed API cannot be changed.
The new scope – allowing something to be seen only by derived members within the same assembly – allows better use of this first style of sharing. To do this without the new scope requires making members internal; internal is more restrictive than protected. But marking members internal gives the false impression that it’s OK for other classes in the assembly to use them.
Far from breaking OOP, the new scope allows encapsulation of the public inheritance API away from the internal mechanics of code reuse convenience. It can be both clear to programmers and enforced that one set of members is present for programming convenience and another set for extension of class behavior.