[Proposal]: Define how to inherit the properties from the parent class

[Monah84]

FEATURE_NAME

Inheritance behavior

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

To define how the behavior of the inheritance. By default, if A is inherited from B, the inheritance is as public by default. The developer can change this behavior to as protected which converts all public properties of the parent class as private in the child class. Therefore, any new class that will be inherited from the child class will not be able to access the parent properties or methods. The developer still can allow some properties to be accessible by using the keyword new .

Motivation

Always I have a problem with defining custom controls where I want to hide the inherited properties from any new child class of my custom control. I believe if we add a restriction or a behavior on the inheritance, it will solve the problem

Detailed design

public class Parent
{
     public int X { get; set;}
     public int Y { get; set;}
}
public class Child : Parent as protected  // <-- here the Child class can access the properties X & Y as private 
{
        public int C { get; set; } 
}

public class A: Child // <-- here the behavior is by default *as public*
{
         // A can see only C property from the class Child while X & Y are hidden
        // if I want to show X to the class A, I have to use new in the class Child
}

• By default the behavior of the Parent class is [as public]
• The user can change the behavior to protected in which all the public methods and properties in the Parent class become private in the Child class.

[svick]

Can you explain in more detail in what situations this would be useful? I especially don't understand how this makes sense, when A could just access the hidden properties anyway by casting this to Parent.

As I understand it, C++ has a similar feature, but there it makes more sense since C++ has multiple inheritance and since "composition over inheritance" wasn't as popular when C++ was first designed.

[HaloFour]

You can use EditorBrowsableAttribute to hide those members in the IDE if you don't want them to appear in autocomplete. As for actually preventing access to those members, that's not possible. The code can always upcast and access them on the parent type.

[Monah84]

I can use this attribute if I am using my own code, for example how to use this attribute for controls coming from different sources like Microsoft or Telerik!? I believe to have the option to control the behaviour of the inheritance will be much better and will give flexibility to the code.

[Monah84]

@Monah84 You know that you can use sealed to prevent override, don't you?
You will not be able to prevent new though.

Furthermore, what about the following?

public class A
{
    public void M() { }
}

public class B : A as private { }

public class C : B { }

void Main()
{
    C c = new C();
    ((A)c).M();
}

You would still be able to use M on c via explicit casts.

Yes, I know about the sealed. This feature is targeting another approach where I can customise other classes in the way I want and to restrict the properties exposed to the clients. In the current approach. All public properties of the parent class (A) are exposed to the client classes ( C in the above example) that are inheriting the child class (B).

Again, my proposal is to add such feature that allow us to prevent the accessibility of the parent class (A) from the client class (C).

[HaloFour]

To my knowledge there is no facility in the runtime to support this. For non-virtual methods there is no way to "remove" them from the derived type. They don't exist there to begin with. When you call derived.Method(), the compiler is actually emitting a call to base.Method().

For virtual methods it's a little different because technically the runtime does allow for an overload to be of a different accessibility, so it would be possible for derived.Method() to be protected or private even if base.Method() is public. But that doesn't help much because the compiler, not finding an accessible derived.Method() to invoke, will just emit a call base.Method() anyway.

In either case I'd suggest that this proposal breaks the contract of inheritance that derived "is a" base, as base has that Member and thus derived must also. Those members will always exist. At best you can shadow/override those members in your derived classes and use the suggested attribute to "hide" those members in the IDE. But you can never prevent them from being invoked.

[Monah84]

I would like to confirm that there is no any break to the inheritance. Class B in the mentioned above still inheriting from A and all the base properties are accessible by the class B but not to the next child. In other word, this inheritance restricted to to the first level of children. If the designer wants to allow more properties to be accessible to the second level of children. The new override can allow this.

Why this level of resistance and refusal on this feature. While in fact, it enriches the tools and gives more flexibility and has not drawbacks on the current existing features!?

[Flutterish]

You could not cast this to parent, making this just copying properties instead of polymorphic inheretance.

[Monah84]

and this is why I am proposing such feature !?

[CyrusNajmabadi]

First, This falls under the bucket of trying to simply make legal stuff not legal. That can be done easily right with an analyzer.

Second, it sounds like a better pattern for you here would be composition, not inheritance. Inheritance is there precisely so you can expose your sub types as instances of the base type (including all is members). If you don't want to allow that, inheritance is likely the wrong till for the job here and you should use composition instead (which naturally gets you the behaviors and surface area you seem to be asking for)

[Monah84]

I would suggest to take some time to think about this feature more. How you deduced that this feature can make the legal thing not legal? In contrary, this features never change the existing things. But it gives more controls for example:

public class A 
{
}

public class B: A // here B will inherit everything from A as usual
{
}

public class D: A as private // here D inherits A but the properties of A becomes private in D and any class inherits from D will not access the properties of A unless we use `new` in D
{
}

where is the illegal part here!? The whole concept is to add flexibility and more control.

Also, Composition is a totally different story and not related to this subject and I am not talking about composition here. How can I get the benefit with the protected properties from composition?

As I mentioned, kindly take some time to think about this feature. I am looking forward to hearing from Mads or any project manager from C#.

[CyrusNajmabadi]

I am looking forward to hearing from Mads or any project manager from C#.

I'm an ldm member and have worked on the C# team prior to C# 1.0 shipping :-)

[CyrusNajmabadi]

public class D: A as private // here D inherits A but the properties of A becomes private in D and any class inherits from D will not access the properties of A unless we use `new` in D
{
}

That breaks here:

A GetA() => new D();
...
var x = GetA().SomeProp;

You can't hide the members because they always be available through the subtypes that your type inherits from.

You may want to consider an analyzer here.

[Monah84]

public class D: A as private // here D inherits A but the properties of A becomes private in D and any class inherits from D will not access the properties of A unless we use `new` in D
{
}

That breaks here:

A GetA() => new D();
...
var x = GetA().SomeProp;

You can't hide the members because they always be available through the subtypes that your type inherits from.

Here is the point, if A was inherited as private. the variable x should not be able to make the cast. Just now, I am working on a Xamarin project and I am extending the Page and wanted to hide properties such as the Content from any new children. This option cannot be achieved neither by composition nor by the current inheritance design. I believe such constraints or restriction can help the developers a lot.

Again, the whole concept is to allow first level inheritance. and the second level of inheritance will not know about the parent class since it is privately inherited.

You may want to consider an analyzer here.

Can you explain more about this point please?

[CyrusNajmabadi]

Can you explain more about this point please?

Write an analyzer that prevents you from casting a D to an A. And which prevents people from using the inherited members on D.