overriding protected internal with protected!

Question

This is an extension for this question asked an hour ago.

We cannot modify the access modifiers, when overriding a virtual method in derived class. Consider Control class in System.Web.UI namespace

public class Control : IComponent, IDisposable,...
{ 
   protected internal virtual void CreateChildControls()
   { }
   .
   .
}

Now Consider This

public class someClass : System.Web.UI.Control
    { 
       // This should not compile but it does
        protected override void CreateChildControls()
        { }

       // This should compile but it does not
        protected internal override void CreateChildControls()
        { }  
    }

can any body explain this ? Thanks

Robbierobbin

Answer 1

We cannot modify the access modifiers when overriding a virtual method in derived class.

That statement is false. You can and must change the access modifiers when in precisely the situation you describe. In other situations you must not change the access modifiers.

I refer you to section 10.6.4 of the specification, which states:

an override declaration cannot change the accessibility of the virtual method. However, if the overridden base method is protected internal and it is declared in a different assembly than the assembly containing the override method then the override method’s declared accessibility must be protected.

The reasoning is straightforward.

You, Asad, have a bank account, BankAccount.

You have a House. You rent a room in House to your best friend Charlie.

Charlie has a son, David, who lives in an Apartment.

You have a son, Elroy, who lives in a Condo.

Elroy has a son, your grandson, Frank, who lives in a Yurt.

Elroy has a best friend Greg who lives in the Condo with him.

You grant access to your BankAccount to yourself, to anyone living in House, and to any of your descendents. So the people who can access the bank account are Asad, Charlie, Elroy, and Frank.

David does not get access because he is neither you, nor your descendent, nor is he living in House. That he is a child of your housemate is irrelevant; he doesn't get access to your BankAccount.

Greg does not get access to your bank account either. He is not your descendent. He does not live in House. The fact that he is living with your descendent does not grant him the same rights as your descendent.

Now we come to the crux of the matter. Elroy is not allowed to extend access to your BankAccount to Greg. You own that BankAccount, and you said "myself, my descendents and my housemates". Your children don't have the right to extend the accessibility of BankAccount beyond what you initially set up.

When Elroy describes what access he has to BankAccount, he is only allowed to say "I grant access to this to myself and my descendents", because that is what you already allowed. He cannot say "I grant access to BankAccount to myself, my descendents and to the other residents of Condo".

Just to be clear:

• I and my descendents get access = protected access
• I and my housemates get access = internal access
• I and my descendents and my housemates get access = protected internal access
• Control = Asad
• CreateChildControls = BankAccount
• House = System.Web.DLL
• Charlie = any type in System.Web.DLL
• David = derived type of Charlie in assembly Apartment.DLL
• Elroy = someClass
• Condo = your assembly containing SomeClass
• Greg = some other class in Condo.DLL
• Frank = derived type of someClass in Yurt.DLL
• Yurt = some other assembly

Gerhardine

So in this situation, what happens when a parent's housemate tries to access what they think is the parent's bank account, but it's actually a child's bank account? IE: Something in System.Web.DLL tries to call the Control.CreateChildControls() (through the internal accessibility), but doesn't have access to someClass.CreateChildControls()? – Premises

Good analogy... except that I wouldn't grant access to my bank account to everybody living in my house ;) – Ramey

@Eric, interesting analogy. One thought - perhaps changing from "who can access my bank account" to "who can drive my car" may make the analogy resonate better with people. – Newborn

Answer 2

Because, while the terminology is different, overriding it as protected keeps the visibility of the member the same. If you were allowed to override it as protected internal, then you would suddenly be exposing the member to any other type in your assembly.

Serial

Answer 3

Protected internal means protected OR internal. So if by overriding outside the original assembly you were allowed to mark it protected internal you would be allowing other classes in the same assembly as the overrider to call this method. That would effectively mean that original parent's internal encapsulation would be violated.

Vallation