Conceptually, is there a difference between a class that extends a module by mixin and a class that inherits another class (single inheritance)?
I know that by mixins , a class can extend multiple modules, which is not allowed in most programming languages with inheritance.
As the concept of mixin varies greatly from implementation to implementation, here I define one that is considered a class (or module) that does not have explicit constructors or states, used to extend behaviors.
Increasingly I am convinced that all these terms are somewhat fragile. It's common to mean different things to different people / communities.
What I've understood so far is that inheritance makes subtype and subclass . And my understanding of mixins is that it only subclasses, so there is an inclusion and not one he inherits parts. I think 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 confusion does not (should) become (r) public. The programmer must deal with the conflicts it may generate, but this only influences internally.
Think of it as an abstract class or a trait that does not create contracts on that type. Its goal is to provide the detail of the implementation, not the API. If it can not be instantiated, nor can it be compared to a concrete class. If you have an implementation, you can not even compare it to the interface. If it is not possible to compare with trait , if it has no type and can not buy with abstract class.
Some people call it private inheritance, and C ++ does so anyway.
It's possible to do a PHP , but I do not think I've ever seen anyone else do it. It is very common for programmers of this language to just follow recipes and do not understand the mechanisms it has and how to use them creatively.
Scala says to have , but I have my doubts if it is mixin even. I have no basis to affirm.
Python can with existing mechanisms.
Of course, Ruby too .
I get the impression that some languages are calling traits from mixins . My understanding is that mixin occurs when the code provides implementations needed to do something that is intended within that type.
In dynamic languages it may be that the concepts merge. In general, they adopt a stance called duck typing , so at the moment the subclass is subclassed, it appears to be the definition of trait .
Although in theory, trait could not have been, and the mixin can. I say, in a thesis, because there are others who question it.
I do not know if a simple composition made in specific form could not be considered a mixture.
A comprehensive explanation .
