Mixins are unique in that they become part of a subclass during compilation. Their methods and constants are included in the subclass. Another unique trait of mixin classes is that methods can be defined and bound to objects at runtime. Most languages use a different approach, binding and defining methods at compile time rather than runtime. This runtime binding allows mixins to be very flexible.
A common problem in multiple inheritance is ambiguity in method calling, and mixins can solve this problem because they don't follow precisely the same rules as multiple inheritance. For example, multiple inheritance can create a so-called "diamond of death," where a parent class A has subclasses B and C, and a class D inherits from both classes B and C. The problem in this scenario is that methods which have the same name in classes A, B and C can all be inherited into class D, making multiple versions of the same method with no clear distinctions. Mixins solve this problem by keeping each version of the method distinct, rather than attempting to overwrite them as in standard multiple inheritance.
Mixins do not override methods in classes into which they are inherited. For example, if a class A defined a method "myMethod" and inherited a mixin B that also defined method "myMethod," both of these methods could still be called without ambiguity, and the implementation of "myMethod" in class A would still be completely accessible. Exactly how these methods would be called depends on the language in which the mixin is implemented.
Some programming languages that do not use mixins, such as Java, use interfaces to mimic them. Interfaces in these languages do not emulate the full functionality of mixins, because interfaces can contain only constants and method declarations. Mixins, on the other hand, can contain full implementations of methods. Those languages that don't support mixins often have viable alternatives that can be coaxed to do roughly the same thing.