Why can't I access C# protected members except like this?

Question

This code:

abstract class C
{
    protected abstract void F(D d);
}

class D : C
{
    protected override void F(D d) { }

    void G(C c)
    {
        c.F(this);
    }
}

Generates this error:

Cannot access protected member 'C.F(D)' via a qualifier of type 'C'; the qualifier must be of type 'D' (or derived from it)

What in the world were they thinking? (Would altering that rule break something?) And is there a way around that aside from making F public?

---

Edit: I now get the reason for why this is (Thanks Greg) but I'm still a bit perplexed as to the rational; given:

class E : C
{
    protected override void F(D d) { }
}  

Why shouldn't D be able to be able to call E.F?

---

The error message is edited so I might have put a typo in there.

Afferent

Your code doesn't compile... It looks like D is supposed to derive from C but it doesn't show this. And if it did, the methods have different visibilities D.F so couldn't be an override of C.F. As you're asking a question about specific language semantics, you need to make your code accurate. – Galvanize

Why should the member F be accessible? Obviously - as with any parameter/variable - you will only see the public interface of the parameter c. – Tale

@divo: why should it be accessible? Because I see no compelling reason that it shouldn't be? – Afferent

@BCS: Part of the idea behind protected methods is to let derived classes decide what abilities from the parent class should be used. If a ReadableFoo offers protected members to set its properties, a MutableFoo could call those members from public setters, while an` ImmutableFoo` could refrain from doing so; if ImmutableFoo is sealed and doesn't use the protected setters, those setters won't be used. If MutableFoo could access the setters from any derivative of ReadableFoo that protection would be lost. – Thumbtack

Answer 1

The "protected" keyword means that only a type and types that derive from that type can access the member. D has no relationship to C therefore cannot access the member.

You have a couple of options if you want to be able to access that member

• Make it public
• Make it internal. This will allow any types to access the member within the same assembly (or other assemblies should you add friend's)
• Derive D from C

EDIT

This scenario is called out in section 3.5.3 of the C# spec.

The reason this is not allowed is because it would allow for cross hierarchy calls. Imagine that in addition to D, there was another base class of C called E. If your code could compile it would allow D to access the member E.F. This type of scenario is not allowed in C# (and I believe the CLR but I don't 100% know).

EDIT2 Why this is bad

Caveat, this is my opinion

The reason this is now allowed is it makes it very difficult to reason about the behavior of a class. The goal of access modifiers is to give the developer control over exactly who can access specific methods. Imagine the following class

sealed class MyClass : C {
  override F(D d) { ... } 
}

Consider what happens if F is a somewhat time critical function. With the current behavior I can reason about the correctness of my class. After all there are only two cases where MyClass.F will be called.

1. Where it's invoked in C
2. Where I explicitly invoke it in MyClass

I can examine these calls and come to a reasonable conclusion about how MyClass functions.

Now, if C# does allow cross hierarchy protected access I can make no such guarantee. Anyone in a completely different assembly can come by and derive from C. Then they can call MyClass.F at will. This makes it completely impossible to reason about the correctness of my class.

Contretemps

I see your point (in edit2) but I still don't like it. It doesn't buy me enough IMHO. – Afferent

"D has no relationship to C", "if you want to be able to access that member ... Derive D from C". But in OP's post: "class D : C". – Aphid

"Anyone in a completely different assembly can come by and derive from C": yes, that is the nature of inheritance. If you allow inheritance, than anyone who inherits your class can write a function that does the opposite of how you designed your function, and C# allows this to happen across assemblies. This answer is making an argument against object-oriented programming. – Flirtation

Thats very smart. How they could think of all these edge case scenarios and not make mistake. Now i see why its prevented, but that wasnt obvious in first place. – Shotgun

None of this explanation is making it any clearer as to why an inherited class cannot invoke a member of the base type anytime it's needed. That's the whole point of "protected". You shouldn't have to make something public for a derived class to access it. If D were not derived from C, there'd be no question. I don't understand why this answer was accepted when it's based on something other than the OPs example. – Selfpreservation

Answer 2

The reason this doesn't work is because C# doesn't allow cross-hierarchy calling of protected methods. Say there was a class E that also derived from C:

  C
 / \
D   E

Then the reference you're trying to call the method on could actually be an instance of type E and thus the method could resolve at runtime to E.F. This is not permitted in C# as D cannot call E's protected methods, because E is in another branch of the hierarchy, i.e.

var d = new D();
var e = new E();
d.G(e); // oops, now this will call E.F which isn't allowed from D

This makes sense because the keyword protected means the member "is accessible within its class and by derived class instances" and E.F is not a member of D.

Galvanize

That is an interesting viewpoint. I had always thought of D.F and E.F as special cases of C.F and thus to be accessible in an all or nothing way. – Afferent

"D cannot call E's protected methods". Assume that C and D are in a assembly and E is in another assembly, and F is protected internal. Then F becomes E's protected member but D can call it. Because from point of view of E F is protected but from point of view of D F will still be protected internal. This always comes a little strange to me :) – Novikoff

Answer 3

Even though D is inherits from C, D cannot access C's protected members. D can access D's protected (and private!) members, so if you put another instance of D in there instead of C everything would work. But as Greg stated, C could really be something completely different, and because the compiler doesn't know what C really is, it has to prevent D from accessing something D may not actually be able to access.

A series of posts explaining this from the C# compiler's perspective:

• Why Can't I Access A Protected Member From A Derived Class
• Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Mantel

+1 for the Eric Lippert links which, as always, explain things much more eloquently than I could hope to (and was probably where I picked up the information in the first place!). – Galvanize

Answer 4

This limitation can be bypassed by using a static protected method:

abstract class C
{
    protected abstract void F (D d);

    // Allows calling F cross-hierarchy for any class derived from C
    protected static void F (C c, D d)
    {
        c.F(d);
    }
}

class D : C
{
    protected override void F (D d) { }

    void G (C c)
    {
        // c.F(this);
        F(c, this);
    }
}

This isn't perfect from security point of view (anyone can derive from C), but if all you care about is hiding method F from the public interface of the class C, this trick may be useful.

Np

Answer 5

Simply put: accessing an instance's protected member is taken as a public access, even if you try to do so from within a derived class. Hence, it's denied.

---

There are many answers here and there, but none of them made it clear to me "why I can't access the protected members of a parent class from a child". That above is what I understood after looking at my code again after reading these confusing answers.

Example:

class Parent
{
    protected int foo = 0;
}

// Child extends from Parent
class Child : Parent
{
    public void SomeThing(Parent p)
    {
        // Here we're trying to access an instance's protected member.
        // So doing this...
        var foo = p.foo;
    }
}

// (this class has nothing to do with the previous ones)
class SomeoneElse
{
    public void SomeThing(Parent p)
    {
        // ...is the same as doing this (i.e. public access).
        var foo = p.foo++;
    }
}

You'd think you'd have access to p.foo because you're inside a child class, but you're accessing it from a instance, and that's like a public access, so it's denied.

You're allowed to access protected members from within the class, not from an instance (yes, we know this):

class Child : Parent
{
    public void SomeThing()
    {
        // I'm allowed to modify parent's protected foo because I'm
        // doing so from within the class.
        foo++;
    }
}

Finally, for the sake of completeness, you are actually able to access an instance's protected and even private members only if you're doing so within the same class:

class Parent
{
    protected int foo = 0;

    private int bar = 0;

    public void SomeThing(Parent p)
    {
        // I'm allowed to access an instance's protected and private
        // members because I'm within Parent accessing a Parent instance
        var foo = p.foo;
        p.bar = 3;
    }
}

Feature

Well that's kinda dumb in C#, accessing an instance of a parent class should not be like public access... – Burmaburman

Answer 6

To understand why this kind of behavior makes sense let's consider why we need access modifiers at all in object oriented programming languages. We need them to limit a scope where a particular class member can be used. And that in turn simplifies searching for the usages.

To summarize:

• to find all usages of public member one needs to search through entire project (and this is not enough in case of library that is used by independent developers)
• to find all usages of protected member one needs to search through the container class and all its subclasses
• to find all usages of private member one needs to search through the container class.

So if the compiler allowed to call protected method from superclass in the described way we could end up with cross-hierarchy calling of protected methods as described in this answer. And in such situation one had to search through all the children of the most parent class that defines the member. And that would increase the scope.

PS. The same behavior is implemented in Java.

Allegiance

Another way of looking it is that .NET wants to promise derived classes that protected members of the base will only be called in ways that they permit [a derived class may prevent sub-derived classes from accessing protected base methods of their parent--at least other than via Reflection--by defining new dummy identifiers which would conflict with the names]. – Thumbtack

Answer 7

Yes, it is possible. We will most probably have such an example very soon.

To do that you must do the following:

1. Inherit the default form (EditAppointmentDialog) and do your customization (you can even use the winforms designer for that).

public partial class CustomAppointmentEditDialog : EditAppointmentDialog { private RadComboBox cmbShowTimeAs = null;

    public CustomAppointmentEditDialog() 
    { 
        InitializeComponent(); 

        this.cmbShowTimeAs = this.Controls["cmbShowTimeAs"] as RadComboBox; 
    } 

    private void chkConfirmed_ToggleStateChanged(object sender, StateChangedEventArgs args) 
    { 
        this.cmbShowTimeAs.SelectedValue = (args.ToggleState == ToggleState.On) ? 
            (int)AppointmentStatus.Busy : (int)AppointmentStatus.Tentative; 
    } 
} 

In the above code I have added an additional check box and set the status (show time as) of the appointment to Tentative if it is unchecked or to Busy if it is checked. The strange way of accessing the combo box is because it is private currently. This will be changed for the upcoming Q1 2009 release.

2. Subscribe to AppointmentEditDialogShowing event of RadScheduler and substitute the default form with your customized one:

private IEditAppointmentDialog appointmentEditDialog = null;

    protected override void OnLoad(EventArgs e) 
    { 
        base.OnLoad(e); 

        this.radScheduler1.AppointmentEditDialogShowing += new EventHandler<AppointmentEditDialogShowingEventArgs>(radScheduler1_AppointmentEditDialogShowing); 
    } 

    void radScheduler1_AppointmentEditDialogShowing(object sender, Telerik.WinControls.UI.AppointmentEditDialogShowingEventArgs e) 
    { 
        if (this.appointmentEditDialog == null) 
        { 
            this.appointmentEditDialog = new CustomAppointmentEditDialog(); 
        } 
        e.AppointmentEditDialog = this.appointmentEditDialog; 
    } 

I hope this helps. Do not hesitate to write me back if you have further questions.

Uvular