Knights, Knaves, Protected and Internal

Knights, Knaves, Protected and Internal

Rate This
  • Comments 42

Knight When you override a virtual method in C# you are required to ensure that the stated accessibility of the overridden method - that is, whether it is public, internal, protected or protected internal(*) – is exactly re-stated in the overriding method. Except in one case. 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.

What the heck is up with that? Surely if an overridden method is protected internal then it only makes sense that the overriding method should be exactly the same: protected internal.

I’ll explain why we have this rule, but first, a brief digression.

A certain island is inhabited by only knights and knaves. Knights make only true statements and only answer questions truthfully; knaves make only false statements and only answer questions untruthfully. If you walk up to an inhabitant of the (aptly-named) Island of Knights and Knaves you can rapidly ascertain whether a particular individual is a knight or a knave by asking a question you know the answer to. For example “does two plus two equal four?” A knight will answer “yes” (**), and a knave will answer “no”. Knaves are prone to saying things like “my mother is a male knight”, which is plainly false.

It might seem at first glance that there is no statement which could be made by both a knight and a knave. Since knights tell the truth and knaves lie, they cannot both make the same statement, right? But in fact there are many statements that can be made by both. Can you think of one?








Both a knight and a knave can say “I am a knight.”

How does that work? The reason this works is because the pronoun “I” refers to different people when uttered by different people. If Alice, a knight, makes the statement “I am a knight”, she is asserting the truth that “Alice is a knight”. If Bob, a knave, makes the statement “I am a knight”, he is not asserting the true statement “Alice is a knight” but rather the false statement “Bob is a knight”. Similarly, both Alice and Bob can assert the statement "My name is Alice," for the same reason.

And that’s why overriding methods in a different assembly aren’t “protected internal”. The modifier “internal” is like a pronoun; it refers to the current assembly. When used in two different assemblies it means different things. The purpose of the rule is to ensure that a derived class does not make the accessibility domain of the virtual member any larger or smaller.

An analogy might help. Suppose a protected resource is a car, an assembly is a dwelling, a person is a class and descendent is a derived class.

  • Alice has a Mazda and lives in House with her good friend Charlie.
  • Charlie has a child, Diana, who lives in Apartment.
  • Alice has a child, Elroy, who lives in Condo with his good friend Greg.
  • Elroy has a child – Alice’s grandchild -- Frank, who lives in Yurt.

Alice grants access to Mazda to anyone living in House and any descendent of Alice. The people who can access Mazda are Alice, Charlie, Elroy, and Frank.

Diana does not get access to Mazda because she is not Alice, not a descendent of Alice, and not a resident of House. That she is a child of Alice’s housemate is irrelevant.

Greg does not get access to Mazda for the same reason: he is not Alice, not a descendent of Alice, and not a resident of House. That he is a housemate of a descendent of Alice is irrelevant. 

Now we come to the crux of the matter. Elroy is not allowed to extend his access to Mazda to Greg. Alice owns that Mazda and she said "myself, my descendents and my housemates". Her children don't have the right to extend the accessibility of Mazda beyond what she initially set up. Nor may Elroy deny access to Frank; as a descendent of Alice, Frank has a right to borrow the car and Greg cannot stop him by making it "private".

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


(*) Private virtual methods are illegal in C#, which irks me to no end. I would totally use that feature if we had it.

(**) Assuming that they answer at all, of course; there could be mute knights and knaves.

  • Eric, I have also found it annoying that you can't create private virtual methods for the case when you have a nested derived class that you want to be able to override the behavior of it's base. An alternative (albeit a hacky one) that I have use in place of private virtual methods is a delegate-based dispatch to the overriding method. Essentially, I'm creating my own virtual function dispatch table. There are numerous improvements that can be made to the code below, but I think it illustrates the pattern:

       class Program


           static void Main(string[] args)


               var animal1 = new Animal.Cat();

               var animal2 = new Animal.Lion();

               Console.WriteLine("animal1 is a " + animal1);

               Console.WriteLine("animal2 is a " + animal2);



       abstract class Animal


           private Func<string> WhatAmI;

           protected Animal() { WhatAmI = ImAnAnimal; }

           public override string ToString() { return WhatAmI(); }

           private string ImAnAnimal() { return "animal"; }

           public class Cat : Animal


               public Cat() { WhatAmI = ImACat; }

               private string ImACat() { return "cat"; }


           public class Lion : Cat


               public Lion() { WhatAmI = ImALion; }

               private string ImALion() { return "lion"; }



  • That's not surprising.  The CLR seems more general than C# in a lot of ways (which I suppose makes sense).  I'm just not clear what the logic is in C#'s restriction, with the possible exception that it might be easier to implement this way.  Although with the introduction of the "protected internal" rule that Eric describes above, it's probably not any simpler any more.

  • @Pavel "Private virtual methods aren't really private in that sense - now you have to document them, all class versioning problems apply to them, etc."

    But if in C# private virtual methods can only be overridden by nested classes, versioning problems are restricted to the code you're already changing anyway. Since all the relevant code is under your control, I don't think there is much of a versioning problem. Documentation, too, seems only necessary to the extent that you document all your other private members.

  • Derek, There IS a big difference. If a derived class overrides a method, then invocations of that method FROM THE BASE CLASS will use the overriden implementation. If a derived class "shadows" a method so that funcationallity can be accessed from outside the class, it does NOT change the behaviour of the BASE class.

  • @Derek, I agree.  I was including the overriding class in the set of potential callers.  They can either call the protected method directly or create a proxy method to expose it publicly.  The only thing that is missing in C# currently is the ability to bypass the proxy method.  Although this is a very flimsy defense for invariants, its better than nothing, so I still feel it should be preserved.  Its kinda like protecting a resource with a pole. I guess I'll have to walk around before I take it.  What I really should have said is that it allows invariants to be broken more easily.

    I think a lot of this comes from access modifiers determining both who can alter the behavior (override) and who can invoke the behavior (call). AFAIK, the use case for most protected methods is to make them overridable in derived classes.  They are not generally intended to be called from arbitrary locations in the derived classes.  The only call from those derived classes is usually to go back up the inheritance chain to invoke the base implementation before/after doing pre/post processing.  What would be ideal is if there was a mechanism by which we could express the need to override the method in any derived class, but only call from the current assembly.

  • @David, I think we're talking about separate concerns.  I wasn't discussing overriding vs hiding/shadowing.  I'm talking about opening accessibility when overriding.  Whether the overriding class changes the behavior of the method is a separate issue from whether the accessibility changes.

    @Chris, I can kind of understand the logic behind restricting the access to exactly that of the base class.  I just think the logic is weak, because I'm not sure it's got any real benefits.  As you pointed out, accessibility addresses multiple concerns.  But it seems pretty trivial to work around the small restriction the same-accessibility rule imposes.  I was really hoping someone could provide either a real-world case that this rule helps, or possibly some other reason for this rule that I'm not aware of.

  • Narrowing access: this is not really possible, anyway. One can always cast your instance to the base class and use the access modifiers initially granted. So if class A has a public method M, and class B tries to restrict it to a private M, calling code could always use ((A)new B()).M().

    Widening: sure, this is actually possible, since a class could expose your protected method through a new public method, delegating the call. But exposing "inner workings" of another class when they weren't meant to is rarely a good idea. So I think it's safer if the language doesn't allow that too easily.

    Private virtual: actually, you have them in C# (with a very slight twist). You can always put the sealed keyword on an override. So this is your private virtual pattern (see remark below, though):

    public class Outer


     private Outer() {}

     protected virtual M() {}

     public class Inner : Outer


       sealed protected override M() {}



    The only "restriction" is that you can't inherit directly from Outer (as that would allow a class to override M). This can be worked around be creating an inner class for that purpose. In all other respects, this is your private virtual pattern: you define some method and only the inner classes can override it. Other classes can be further inherited, but they can't modify M anymore.

  • "But if you want to create a virtual method that only precisely those derived classes you know about can override, the best you can do is make it internal."

    If something is internal, then only classes in the contained assembly know about it, right? And if it's in my assembly, then I know about, right? So how would "private virtual" give me any expressive abilities that I don't already have?

  • @Derek, but if you open the accessability, then you provde the capability for OTHER classes to ALSO CHANGE THE BEHAVIOR [by having them create an additional override!

  • Dear Eric,

    I just came by to say that this Blog is amazing, I have been following your posts for more than a year, and found it really interesting. each post has something for me to learn, and always described in an easy way.

    This post was also one of them that made me smile when I finished reading it.

  • @Gabe

    "f something is internal, then only classes in the contained assembly know about it, right? And if it's in my assembly, then I know about, right? So how would "private virtual" give me any expressive abilities that I don't already have?"


    class Parent


       private Parent() {}

       private virtual Method() {...}

       class NestedInheritedClass: Parent


            private override Method {...} //Valid as its accessible



    class ExternalInheritedClass: NestedInheritedClass


       private override Method {...} //No cigar. Method is not accessible.


    What you can do through this mechanism is allow the nested inherited classes to override some virtual methods while you dissallow all external classes of the same assembly from ever being able to override said method. Right now you can't do that. You can dissallow classes from other assemblies of ever doing that, but not classes that belong to the same assembly.

    At least thats what I think Eric is saying.

  • > And if it's in my assembly, then I know about, right?

    Not really. Dump some stock assembly from BCL using ildasm sometime, and count the number of types within.

  • Isn't making the constructor private sufficient to restrict only nested classes from overriding protected methods (marking those overrides sealed)?

  • @David

    > but if you open the accessability, then you provde the capability for OTHER classes to ALSO CHANGE THE BEHAVIOR [by having them create an additional override!

    Unless the function is declared internal *only*, this capability already exists.  If class A declares function f() as protected, B (extending A) can override it, and C (extending B) can also override it.  This would be the case regardless of whether B makes the permissions on f() more open or not.

    In fact, this is the case even in the case of an internal-only function.  e.g. A declares f() as internal.  B (extending A, same assembly) declares g() virtual, *and* overrides f() to just call g().  C (extending B, but in a different assembly), can now change the behavior of f() by overriding g().

    If a class allows subclassing and overriding, it is trusting those subclasses to do the right thing.  But it cannot force them to.

  • > Isn't making the constructor private sufficient to restrict only nested classes from overriding protected methods (marking those overrides sealed)?

    It is, but it also prevents outside assemblies from deriving in general, which may not be what is desired.

    (though, to be honest, I've never actually ran into a case where private constructor + nested wouldn't be enough)

Page 2 of 3 (42 items) 123