Mix-ins. Think Java 8 interfaces, with default implementations (so you can still have a putAll method as part of the interface, but the default handles the looping logic for you).
You can also do a layering-up type thing, where you have a base class that implements particular functionality, and inheriting from particular classes surfaces it or restricts it in particular ways.
Indeed. And once you have interfaces with default implementations, adding state gets you even more power. For example, intrusive reference counting and intrusive data structures generally are very useful applications of multiple inheritance.
I wrote a report about how using Objective-C categories to implement UIViewController feature modules can be really elegant. [1] The same would be true, I imagine, for what would be Swift's multiple inheritance. The following is a quick summary of this report, with thoughts about multiple inheritance.
You may find yourself having a set of UIViewControllers that implement overlapping subsets of the features that your app provides (i.e. one controller has features A and B, another has features B and C, a third has features C and A).
One method of solving this is to create helper modules that implement the features A, B, and C. In your controllers, you can then set up the appropriate subset of helper modules. There are a few problems with this: 1) there's still boilerplate code; 2) the implementation can be subtle (make sure to retain the reference to all your helper classes!).
This can be elegantly solved with Objective-C categories (by creating a category for each feature) or, I imagine, what multiple inheritance would look like in Swift. Instead of boilerplate helper module initialization and subtle implementation, your ABUIViewController could inherit from abstract AUIViewController and BUIViewController base classes to get both features for free in virtual methods.
Here's the canonical example I used to quote for multiple inheritance: "Implementing the design pattern observer".
You basically want to add public methods addEventListener(), removeEventListener() and a protected fireEvent() method. In Java you have no problem inheriting the interface for these methods. However you want to manually re-implement the damn implementation in each class that vends interface. I can't remember how many times I wrote these...
In C++ with multiple inheritance you can inherit both the interface and implementation, and you're done. It is one step further than Java interfaces.
These days, I don't use that so much and I would not miss multiple inheritance. I prefer to implement the design pattern observer through signals (boost::signal in C++, custom classes in JavaScript/TypeScript). C# delegates provide a good solution for this problem too.
I have not touched Java since 1.4, so maybe there is a more elegant way to solve this now...
You basically want to add public methods addEventListener(), removeEventListener() and a protected fireEvent() method. In Java you have no problem inheriting the interface for these methods. However you want to manually re-implement the damn implementation in each class that vends interface. I can't remember how many times I wrote these...
Why? Just use composition and delegate addEventListener() and removeEventListener() to the member implementing the logic?
That's a good idea. And as that's a common pattern, you could allow the programmer to specify that the compiler should automatically implement this delegation. You could call this feature something like, I don't know, "multiple inheritance".
Then you don't understand composition. I can pass the actual implementation in the constructor or via dependency injection. With multiple inheritance, your class is restricted to one implementation. Moreover, it couples the class with the internals of observables, rather than using simple interfaces, which composition provides.
IMHO multiple inheritance is a bad solution to this problem. I would be more inclined to use a DI pattern and inject an event manager wherever it's needed.
Even when multiple inheritance is genuinely useful, it still feels dirty to me. PHP actually has a nice feature called traits, which is essentially compiler-assisted copy & paste. It means you can re-use code without duplication and without the confusion that multiple inheritance can bring.
Honest question: Why would you ever want to use multiple inheritance? It seems like an awful design pattern.
I mean, in C++, you basically just end up with a more confusing equivalent to Java interfaces.