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
protected: The type or member can be accessed only by code in the same class , or in a class that is derived from that class . internal: The type or member can be accessed by any code in the same assembly, but not from another assembly.
So, a protected function can be overridden as either protected or public , but it can't be overridden as private , and a public function can only be overridden as public .
If the superclass method is protected, the subclass overridden method can have protected or public (but not default or private) which means the subclass overridden method can not have a weaker access specifier.
The protected internal keyword combination is a member access modifier. A protected internal member is accessible from the current assembly or from types that are derived from the containing class. For a comparison of protected internal with the other access modifiers, see Accessibility Levels.
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With