Add multiple inheritance

[rurapente]

Perl supports multiple inheritance ("C3 linearization").
Python supports multiple inheritance ("C3 linearization").
Common Lisp supports multiple inheritance.
Pascal supports muliple inheritance ("last man standing").
OCaml supports multiple inheritance.
Tcl allows multiple inheritance (C3 linearization).
C++ supports multiple inheritance.

Why not C# ?

In Eiffel, the ancestors' features are chosen explicitly with select and rename directives. This allows the features of the base class to be shared between its descendants or to give each of them a separate copy of the base class.

Go prevents the diamond problem at compile time. If a structure D embeds two structures B and C which both have a method F(), thus satisfying an interface A, the compiler will complain about an "ambiguous selector" if D.F() is called, or if an instance of D is assigned to a variable of type A. B and C's methods can be called explicitly with D.B.F() or D.C.F().

Why not just use composition, and automagically add proxy methods/properties on the object, with select and rename directives in case of name collision ?

Usage Example:

// Implement once
abstract class BaseDBAL
{
        protected string m_cachedConnnectionString;

        private string Fetch()
       {
               return readFromAssociativeArrayFromConfigByMachineNameAndDecryptPassword();
       }

        public virtual string GetConnectionString()
       {
               if(m_cachedConnnectionString != null) 
                    return m_cachedConnnectionString;
               m_cachedConnnectionString = Fetch();
               return m_cachedConnnectionString;
       }

}

// Read on slave
abstract class ReadDBAL : BaseDBAL
{
        public virtual DataTable GetTable();
}

// Write on Master
abstract class WriteDBAL : BaseDBAL
{
        public virtual void ExecuteNonQuery();
}

// Multiple inheritance - don't want to redeclare interface 1000 times when it's constantly changing...
abstract class ReadWriteDBAL : ReadDBAL, WriteDBAL
{
      // Don't redeclare interface - DRY
       public override ReadDBAL.GetConnectionString alias GetConnectionString2
      {
              return WriteDBAL.GetConnectionString();
      }
}

Multiple inheritance from same class

abstract class ReadWriteDBAL : ReadDBAL alias Read1, ReadDBAL alias Read2  
{
       protected Read1.m_cachedConnnectionString alias-omit; // Is always blank due to override, so hide/omit this member
       protected Read2.m_cachedConnnectionString alias MyConnectionString;


       public override Read1.GetConnectionString alias GetConnectionString2
      {
              return Read2.GetConnectionString();
      }
}

[HaloFour]

Why not C# ?

The correct question isn't "why not", it's "why?" Why should C# support MI? What problems does it solve that can't be solved today through composition?

C# doesn't support MI because the CLR doesn't support MI. The diamond issue with methods is probably the easiest problem for the CLR and C# to solve since virtual slots can be renamed or even hidden. The bigger issue would be state, particularly if/when it should be shared between multiple instances common ancestors.

With C# effectively getting traits and multiple-inheritance of behavior I'd say that any perceived need for this would be greatly diminished.

[dzmitry-lahoda]

c3 allows to write middlewares without runtime reflection of dependency injection containers.

[erik-kallen]

The diamond problem could be solved by disallowing it, if we wanted to. Though personally I don't think MI is necessary.

[Vlad-Stryapko]

@HaloFour

The bigger issue would be state, particularly if/when it should be shared between multiple instances common ancestors.

Could you please elaborate on that? I often see this argument but I could never quite grasp what it means.

As to the proposal, I don't think it's worth it. I was in the minority of people who were happy with Default Interfaces but I don't think we need to go further than that and even Default Interfaces turned out to be quite a complex feature.

[HaloFour]

@Vlad-Stryapko

Could you please elaborate on that? I often see this argument but I could never quite grasp what it means.

When you inherit from a class you inherit all of its fields, and all of the fields of its ancestors as well. When you bring multiple-inheritance into the mix all you end up inheriting the fields of all of the base classes and their ancestors. But what happens if you inherit from two classes that share the same ancestor? Do they each have their own copy of the fields from the ancestor class, or do they share those fields?

As to the proposal, I don't think it's worth it. I was in the minority of people who were happy with Default Interfaces but I don't think we need to go further than that and even Default Interfaces turned out to be quite a complex feature.

Even with the baseline functionality it enables support for traits as each interface can have the default logic baked in. I'd suspect that private and protected members would be supported as well as they enable shared helper functions and quasi-state. I don't think it's appreciably more complicated than what Java supports, except that C# has significantly more options since you have much more flexibility when overriding virtual slots, which will make it easier to handle diamond/collision situations better.

[Vlad-Stryapko]

@HaloFour
My confusion was that in C# state can also be expressed as properties and they're allowed in interfaces, so I though we still had a problem. However, as it turns out, I've missed something with Default Interfaces - they do now allow automatic properties. Thanks for clarification.

[gafter]

The default interface implementation feature permits multiple inheritance without the problems associated with multiple inheritance of state.

[ststeiger]

@gafter: Such as a property that needs access to a state variable ;)

To be fair, the "Why not" sounds like bullshit.
When you need "interfaces" with default-implementations, you actually need an abstract class.
And an abstract class allows for implementation of methods that access "state".

The better question is: Why interfaces ?
An abstract class can do everything an interface can, plus more - it's a superset of interfaces.
You can't even implement an abstract class as an interface, because you cannot implement a functional superset from a functional subset.

If C# would properly support multiple inheritance, you wouldn't need interfaces, and you wouldn't need interface-default-methods...

To quote George Bernhard Shaw

Some people see things and say: "Why ?"
But I dream of things that never were; and I say: Why not !

All you would need is composition variable, e.g.:

A.bases.B.bases.C
A.bases.D.bases.C

Then you can use select and rename directives in the cases where there is a name-collision , and for all where there is no collision, you don't need select-and-rename. Doesn't sound so difficult.

[ufcpp]

How about using code generator for stateful mixins. For instance, I implemented a code generator for that purpose.

[ststeiger]

@ufcpp: Yea, now automate the mixin, call it inheritance, and it's done.

[gafter]

@gafter: Such as a property that needs access to a state variable ;)

No. "needing access to state" isn't the problem. It is the multiple inheritance of the state itself that is the root of most problems cited with multiple inheritance.

When you need "interfaces" with default-implementations, you actually need an abstract class.

No, programmers do not require that their problems be solved by a particular language construct. They require that their problem be solved by some language construct.

[ststeiger]

No, programmers do not require that their problems be solved by a particular language construct. They require that their problem be solved by some language construct.

Don't tell me (or anybody else) what I'm supposed to want or don't want.
I know what I want.
This may not be what you want, but it still is what >I< want.

No. "needing access to state" isn't the problem. It is the multiple inheritance of the state itself that is the root of most problems cited with multiple inheritance.

Which isn't really a problem if you implement MI through composition and renameable proxy-methods.
The base problem is rather that single-inhertiance wasn't implemented through composition and renamable auto/generated-proxy-methods/properties/fields, and now it's resulting in a mess if you want to implement multiple inheritance.

[HaloFour]

@ststeiger

This may not be what you want, but it still is what >I< want.

You're free to fork and design the language in your own image.

[ststeiger]

@HaloFour: Would like to, but hardly have the time to write these comments, let alone fork C#.
Also, I'd rather work on my bitcoin arbitrage bot than "on some infrastructure that should already exist int he first place" - whether I use C# or GO or NodeJS to interact with R/Julia - who cares - I can life with all of them (sometimes even better).

[bondsbw]

"on some infrastructure that should already exist int he first place"

The should is your opinion. It can only turn into an expectation if you can convince the right people to take up your cause, by convincing them that MI is worth de-prioritizing other features. I for one (not that I am "the right people") haven't been convinced that MI is even a positive feature, worth implementing if there was no other work left to do.

[ststeiger]

OK, I give up - obviously, arrow properties and default-interface implementations are more important than MI ...
It's just sad having to read this crap.

Uncle Bob has a good read here:
http://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmful.html

[HaloFour]

Oh, one random blog post. I'm convinced. It's not like anybody ever wrote about there being problems with MI.

[ststeiger]

@gafter: Haha, no I certainly don't believe that, and no, didn't know.
Sure there are problems with MI, I don't deny that - but there are problems and tradeoffs for pretty much anything.

And OK - yes, if a complete platform overhaul is financially out of the question, then so is MI.
But then an honest answer would be "it's too expensive to implement", and not "you don't need it".

However, that probably means that in the future, I'm gonna forgo any kind of inheritance that doesn't involve an abstract class, and just use composition with abstract classes instead, as everything else doesn't make much sense (IMHO).

Which will then look something like this:

    public abstract class ReadDBAL
    {
        public static ReadDBAL Create(string providerName)
        {
            if ("Npgsql".Equals(providerName, System.StringComparison.InvariantCultureIgnoreCase))
            {
                return new PgReadDBAL();
            }

            return null;
        }
    }

    public abstract class WriteDBAL
    {

        public static WriteDBAL Create(string providerName)
        {
            if ("Npgsql".Equals(providerName, System.StringComparison.InvariantCultureIgnoreCase))
            {
                return new PgWriteDBAL();
            }

            return null;
        }
    }

    public abstract class SQL
    {
        public ReadDBAL Read;
        public WriteDBAL Write;

        public static SQL Create(string providerName)
        {
            PgDBAL instance = new PgDBAL();
            instance.Read = ReadDBAL.Create(providerName);
            instance.Write = WriteDBAL.Create(providerName);

            return instance;
        }

    }

    public class PgReadDBAL : ReadDBAL
    { }

    public class PgWriteDBAL : WriteDBAL
    { }

    public class PgDBAL : SQL
    { }

DI:
services.AddSingleton(SQL.Create());`

Because if I wanted to do this with interfaces and later extend them, which requires interface-defaults if compilation isn't to be broken - I'd still need to share the connection string, and other things - not that an evil plugin-author couldn't access it by reflection anyway.

[Joe4evr]

@VisualMelon As part of the Default Implementations feature, you're gonna be allowed to specify an access modifier on interface members, so that would solve your visibility complaint.

[VisualMelon]

@Joe4evr thanks, I keep forgetting that (terribly important!) detail.

[MaStr11]

@Joe4evr That doesn't help. Private members need an implementation (You can try in the sharplab sample by yourself. It doesn't compile). @VisualMelon is right with leaves the list of observers public. The best you could do is explicit implement List<Observer> Observers { get; }

[VisualMelon]

@MaStr11 aye, it's still not ideal, but it isn't nearly as bad (only the implementer has to worry about it, it doesn't escape to the consumer)

[HaloFour]

@MaStr11

That doesn't help. Private members need an implementation

Yes, but protected members won't.

[Joe4evr]

@MaStr11 I got it working this way.

[MaStr11]

@HaloFour

Yes, but protected members won't.

From what I can see that's not decided yet:

Open Issue: We need to specify the precise meaning of the access modifiers such as protected and internal, and which declarations do and do not override them (in a derived interface) or implement them (in a class that implements the interface).

The current implementation gives an CS0106: The modifier 'protected' is not valid for this item. We will see.

[masonwheeler]

Pascal supports muliple inheritance ("last man standing").

Huh?

I come from a strong Pascal background and I've never heard of this. A bit of Googling shows it's a very obscure technique for dealing with poor practice in coding, but it has nothing to do with multiple inheritance (a class having more than one direct parent class), which no Pascal variant I'm familiar with supports.

[ekolis]

Regarding the diamond problem, couldn't this be solved by checking the order of declaration of superclasses and/or explicit declarations? eg.

public abstract class Creature
{
	public abstract void Think();
}

public class Animal : Creature
{
	public override void Think()
	{
		throw new NotSupportedException();
	}
}

public class SentientBeing : Creature
{
	public override void Think()
	{
		Console.WriteLine("hmm");
	}
}

public class Human : SentientBeing, Animal
{
	// Human.Think() uses the SentientBeing implementation because SentientBeing is declared first in the inheritance list
}

public class Alien : Animal, SentientBeing
{
	// explicitly declare which implementation we are using
	public override void Think() : SentientBeing;
}

[bondsbw]

@ekolis Adding a conflicting method to the first class would cause a breaking change.

[Xyncgas]

#5508

[NCLnclNCL]

I need it

[KennethHoff]

For things like this we need a very clear guiding use-case; what problem are you trying to solve? Are there no better ways of solving that problem?

[gafter]

C# supports multiple inheritance in interfaces.

[dzmitry-lahoda]

also interfaces cannot do operators to inherit implicit casts (i did not checked for last 2 years) and implicit casts are out of inheritance system #6050

MI could solve it by allowing to inherit 2 classes with own operators.

[gafter]

MI in C# interfaces uses the same solution as in Go and Java.

[dzmitry-lahoda]

Go allows to inherit state from several structs and delegate calls to the.
m with relevant conflict resolution.

https://gobyexample.com/struct-embedding,

which is MI.

in C# there is not such feature.

[dzmitry-lahoda]

internet says Java supports MI exactly as C#, indeed. by not supporting it.

[HaloFour]

C# isn't going to get MI, and given C3 exists specifically to try to make sense of the insanity that MI creates, it seems that it would be a very good thing that C# doesn't do C3.

[TahirAhmadov]

In case anybody finds it useful, check out my composition SG
https://github.com/TahirAhmadov/Composition?tab=readme-ov-file

[AndersKehlet]

How much work do you think an incremental version would be?

[TahirAhmadov]

Probably not that much, because most of the complexity is the generation itself. However, I haven't made any attempts to convert it, and my "not that much" estimation is based on a couple of other incremental SGs I wrote.

[AndersKehlet]

I may have a go at it then. You've already done the heavy lifting, as you say. :)