(Surprisingly) unpopular opinion: Multiple inheritance is a bad design practice and should not be used.

How is that unpopular? C# and Java both decided to avoid this feature just because of that.

@HitWRight Honestly, I hear people complaining about the absence of multiple inheritance in Java and C# all the time. And I just cannot understand how people would want that. Having worked with C++ myself for years, everytime I see a class using multiple inheritance you can bet it is either an extremely shitty design by some noob, or some quick-fix with a TODO that says "FIX THIS LATER!".

Unpopular opinion: inheritance and objects were a bad idea all from the start.

@p100sch Come to my heart, brother!

Multiple inheritance is only needed if you have inheritance in the first place.

And you know what they say about inheritance:

Composability over inheritance. Which means implement over extend. Or interface over abstract class.

So, please stick your classes in your butt... and give me struct/trait/impl (Rust), or function/type/typeclass (Haskell).

In Haskell, "<" is not an operator, it's a function, with type (Ord a => a -> a -> Bool). Which means that if I define a Type "car" and implement the Ord "interface" for it, I can "<" and ">" my cars, and also sort my cars.

The issue with OOP languages is that while some of them have similar typesystems as FP languages (classes are types, interfaces are typeclasses), they lack flexibility for implementation.

That's why Rust chose to NOT be OOP.

In FP(ish) languages, implementations generalized, not encapsulated.

You define function (sort :: Ord a => [a] -> [a]), and ANYTHING that identifies as an Ord can be sorted.

I don't want to get into gender politics here, but imagine a system where Boy/Girl class inherits from a Human class, which extends from Mammal, etc.

Now you're born with a vagina, but feel like a guy who falls in love with women.

Wouldn't it be easier if you aren't a Boy or a Girl, or even Human... you just implement some typeclasses/traits to describe which parts you have, and which relations you form?

Also makes your code easier to extend when you build some AI in a male/female robot body. Or crossbreed cats and girls into neko...

ugh OK stick to your OOP, guys.

Multiple inheritance is in my (unpopular) opinion about as bad as passing parameters down constructors and function... 1 is good, 2 are fine, 3 is starting to get ugly and 4 you' should re-design it.

Through with inheritance I'd usually stop at 2 most because that may already imply a bad design..

It's like having a car class implement both "vehicle" and "animal" or something... But there are edge cases where it can still be more readable than avoiding it probably. Dunno, rarely do I ever use more than 1 parent class

People that hate inheritance just aren't using it properly. It's a modeling approach for solving code duplication and it makes sense.

The whole debate of composition vs inheritance is imho dumb because those two approaches aren't XOR'd. Use the one that has more advantage in terms of readability, ease of use and performance...

But that's just me...

@halfflat Actually from what I have seen multiple inheritance does not help code re-use that much. I mean inheritance itself always seems to lead to unnecessary bundling of functionality, which inhibits code re-use, and multiple inheritance loosens that up a bit. But using composition instead improved re-use much more than that in the refactorings I've done.

Mixins I'll not comment on other than I would not use them if I was forced with a gun to my head.

That's a fairly popular opinion...

I find that the Java / C# approach of handling it is far better.

@ostream Lol, OOP is not shit. Just because you aren't comfortable with it doesn't make it bad, all forms of programming have some merit and some methods work better than others, entirely dependent on the task.

I feel like the more experienced you are, the more you start to dislike OOP. And most people like OOP when they start programming.

Hmmmmmmmmm

I think the problem lies rather in "it's kinky let's do it" vs "this is a pragmatic approach, battle proven".

Kinky - let's do it: a lot of stuff in OOP is in theory "sound" / "doable".

In reality, you'll end up with garbage - as the complexity far exceeds it's usefulness.

"kinky" are e.g. multi inheritance, reflection, templating, ...

There can be useful cases - without a doubt - but most of the time it _should_ be solved in an easier way if possible.

To put it in a simple phrase: "Choose your enemies wisely".

That's what the pragmatic, battle proven approach does.

Instead of looking for a general, reusable, abstract solution, it's most of the time more viable to stay concrete first and adapt to a more general approach only if necessary.

This is where most of OOP implementations go south: Devs trying to be OOP zealots and solving everything in the most complex way:

When it's 1 plus 1, it should be 2.

It shouldn't be an calculator that covers NaN, negative numbers, floats, and all the other stuff...

Just 1 plus 1 and be done.

OOP isn't bad - but it can become a nightmare, like all other things in programming.

FP is the same. :)

@IntrusionCM damn! I wanted to agree but then I read your last sentence. How dare you comparing OOP with FP? Obviously FP can and should be used for everything! 😅

@Lensflare with age comes perversion.

Fine butt btw.

:)

@IntrusionCM only procedural is the only true method 😏

@bittersweet

In C++, operator< is a function too