Why Can't I Access A Protected Member From A Derived Class, Part Three

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Roman — Wed, 18 Aug 2010 10:02:37 GMT

> If the member is already marked as internal then the only people who can use it are your coworkers.

It is clear that C# has been designed around this concept, and that's fair enough. I do find it limiting though. Oftentimes I want to protect my own code _from myself_ misusing it by accident. I want to be able to write bullet-proof code that I _cannot_ possibly abuse - even if I don't have malicious intent.

Unfortunately, in C#, if the code consists of at least two classes interacting with each other then almost always the only way to make it bullet-proof to accidental abuse is to stick it into a separate assembly.

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Timwi — Tue, 17 Aug 2010 23:35:46 GMT

> You get NO additional security by going to "protected and internal" because your coworker can simply write a subclass to party on the member.

Isn’t this the same argument as saying, you get no additional security by going “private” because your coworker can simply write a public method to party on the member? If you think this is a strawman, please elucidate.

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

LeatHakkor — Thu, 15 Jul 2010 00:39:36 GMT

Forgot to mention that there is a way to make members virtual, I have never had a need to do it, but it does work using delegates, Function<T>, Action<T>, and poor-man's dependency injection (www.lostechies.com/.../how-not-to-do-dependency-injection-in-nerddinner.aspx)

If you NEED the sample email me, its substantially longer than this snippet.

var email = string.Concat( @"leat" + "hakkor", "@", "hot", "mail", @".", "com" );

^^ Take that spammers

[Scott Youngblut (MCPD)]

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

LeatHakkor — Wed, 14 Jul 2010 13:56:30 GMT

It's a common belief that you cannot make some members both protected AND internal.

And its true that you cannot do so in a single line, as many, including myself, would wish, but with some cleverness it is 100% do-able. I'll Let my (hopefully) self-documenting code speak for itself.

[START C# CODE]

//Code below is 100% tested

/* FROM ProtectedAndInternal.dll */

namespace ProtectedAndInternal

{

public class MyServiceImplementationBase

{

protected static class RelevantStrings

{

internal static string AppName = "Kickin' Code";

internal static string AppAuthor = "Scott Youngblut";

}

public class MyServiceImplementation : MyServiceImplementationBase

{

public void PrintProperties()

{

// WORKS PERFECTLY BECAUSE SAME ASSEMBLY!

Console.WriteLine(RelevantStrings.AppAuthor);

}

public class NotMyServiceImplementation

{

public void PrintProperties()

{

// FAILS - NOT THE CORRECT INHERITANCE CHAIN

// Error CS0122: 'ProtectedAndInternal.MyServiceImplementationBase.Relevant' is inaccessible due to its protection level

// Console.WriteLine(MyServiceImplementationBase.RelevantStrings.AppAuthor);

}

/* From AlternateAssemblyService.dll which references ProtectedAndInternal.dll */

namespace AlternateAssemblyService

{

public class MyServiceImplementation : MyServiceImplementationBase

{

public void PrintProperties()

{

// FAILS - NOT THE CORRECT ASSEMBLY

// Error CS0117: 'ProtectedAndInternal.MyServiceImplementationBase.RelevantStrings' does not contain a definition for 'AppAuthor'

// Console.WriteLine(RelevantStrings.AppAuthor);

}

[END C# CODE]

[CopyRight - Scott Youngblut (MCPD)]

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Timwi — Tue, 13 Apr 2010 12:23:52 GMT

I don't entirely agree with your analysis of people's perception. I don't think people conceive of "internal", "protected" and "private" as restrictions because they think of "public" as some sort of "natural" state. I think they conceive of them as restrictions because the words themselves emphasise that they are a restriction; especially "protected" and "internal". They both sound much more like "stop someone from doing something" than "allow someone to do something".

I have no idea what they could have been called instead, but this explains why the "wrong" intuition is so common.

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

JD — Thu, 05 Jun 2008 19:27:05 GMT

Customer feedback is right on this one. 'protected internal' should be FamilyAndAssembly.

The main paractical effect of these attributes is to give compiler errors when someone does something wrong. So do I want to give a compiler error to my coworker who is not derived from my class? Yes.

You can argue that it also affects CAS and verification, and that is a very powerful argument. But by the measure of security, the C# team got the decision wrong. Because nearly everyone adding 'protected internal' is expecting it to be restrictive, and is surprised to learn of the contrary *if* they check their assumptions. So C# has undermined (not helped) CAS by making it more likely for developers to introduce vulnerabilities in their code.

I would cut some slack based on design goals though. Because C# was clearly built to work well (better!) for developers with Java and C++ backgrounds. In Java is there a "package protected" (I honestly have no clue)? In C++ there aren't really sassemblies as such, but can 'friend' access 'portected' members (since they can access privates, I assume so).

To put it a different way, who does the current 'protected internal' help? It only helps non-subclassed code in the assembly have access to protected members. This is trivially possible (and arguably better modeled) by adding a regular internal method anyway. Maybe Java "protected package" did soemthing like this and it was a competitive response? I really don't understand how this made the bar to get into the language spec as is.

Honestly, from reading your article it sounds like there was some champion who really believed the 'access modifiers are a loosening of the private constraint' and no one else cared enough to argue back strongly.

VCS Team Links for May 22, 2008

Charlie Calvert's Community Blog — Thu, 22 May 2008 22:23:28 GMT

Rather than place the links to the most recent C# team content directly in Community Convergence , I

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Marcel Popescu — Fri, 02 May 2008 00:33:01 GMT

"If it is intended to be accessible to internal subclasses, then what is the harm of it being accessible to internal non-subclasses? You get NO additional security by going to "protected and internal" because your coworker can simply write a subclass to party on the member."

Ahem.

double d = 5.0;

int i = d;

Why isn't the above allowed? You can simply write

int i = (int)d;

The whole point is to force you to cast it, so that you have to think if that's what you want. Same thing with writing a subclass to allow access to a "protected AND internal" member - it means that you thought about it and decided that yes, you really really want access to that member.

"Not a high enough priority" is a good argument. "Not useful" is a lousy one.

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Josh Berke — Tue, 29 Apr 2008 16:15:26 GMT

I was one of the peolpe who had always thought that protected internal would work to make things more restrictive. I never sat back and thought about how private is default so it would as you would say loosen restrictions.

I disagree with your thought that there is no need for a "Proternal" since your trying to protect your own co-workers. One case where this comes into play is when a project enters maintneance mode and the original developers are no longer there. Something marked as "Proternal" helps to clearify the intent that only derived classes within this assembly should be using this method.

On the same token I'd rather see other cooler language enhancements then this feature which would only be applicable a small percentage of time.

I agree on sealing but I like that classes are not sealed by default. If developers had to consiously unseal thigns, then I am going to guess that a lot of the controls which I like to derive would be sealed and I'd end up having to use some sort of delegation.

Nice Post;-)

re: Why Can't I Access A Protected Member From A Derived Class, Part Three

Kor Nielsen — Mon, 28 Apr 2008 21:58:48 GMT

James: The main problem with using a protected method with an internal constructor is that sometimes you want to use internal types as parameters to your protected method. If your class is public, that is not a possibility. So far, the best approach I've found is to make the class internal and expose a public interface.