What is the difference between mixins and inheritance?

Question

Conceptually, there is a difference between a class that extends a module by mixin and a class that inherits another class (unique inheritance)?

I know why mixins, a class can extend multiple modules, which is not allowed in most programming languages with inheritance.

As the concept of mixin varies a lot from implementation to implementation, here I define the one that considers a class (or module) that has no explicit constructors and no states, used to extend behaviors.

Answer 1

I am increasingly convinced that all these terms are a little fragile. It is common to mean different things to different people/communities.

What I understood until today is that the inheritance makes subtype and subclass. And my understanding about mixins is that he only does subclass, so there is an inclusion and not an inheritance, it mixes parts. I find the idea "wrong" there, is the "extends", there is no extension, there is inclusion.

In theory it is easier to mix several parts because the type contract is not present, there is no confusion. It is not that there is zero confusion, it is that the confusion is not (should) public (r). The programmer must deal with the conflicts it can generate, but this only influences internally.

Think of it as an abstract class or an trait that does not create contracts of that type. Its purpose is to provide the detail of the implementation, not the API. If it can’t be instantiated, you can’t compare it to a concrete class. If you have an implementation, you can’t compare it to an interface. If there’s a state you can’t even compare to trait, If you don’t have the type and you can’t buy with abstract class.

Some people call it a private inheritance, and C++ does so even.

D does it with templates.

It is possible to make a PHP, But I don’t think I’ve ever seen anyone do it. It is very common that the programmers of this language only follow recipes and do not understand the mechanisms that it has and how to use them creatively, which can be good if it is to do wrong.

Scala claims to have, but I have my doubts whether it is mixin same. I have no basis to state.

Python can do with existing mechanisms.

And of course, Ruby also, is very popular in it.

I have the impression that some languages are calling traits of mixins. My understanding is that the mixin occurs when the code provides implementations necessary to do something intended within that type.

In dynamic languages it may be that concepts mix. In general they adopt a posture called Duck Typing, then the moment you subclass the subtype gets subtype, and that seems to be the definition of trait.

Although, in theory, the trait could not have been, and the mixin can. I mean, in a thesis, because there are other people who question this.

I do not know if a simple composition made in a specific form could not be considered a mixture.

One extensive explanation.

More information.