Oh absolutely, the type enhancement is what makes it so interesting to use, but the point is that it's not necessary for it to be a mixin. It's a very nice extra.
I'm not sure about python, but Ruby completely inlines the mixin's code. It needs to do this because instance variables can be created anywhere, including from inside the mixin, but they still need to apply to the object of the actual class. This gives interesting cases for collisions, where 2 mixins create the same instance variable, but it's a decidedly non-inheritance way of doing it.
I use a mixin pattern extensively in C# that involves an interface to say the object provides a mixin object (C# also provides for partial classes, but its not good enough). Polymorphism is preserved via this method (though all clients delegate through MixX). Actually, I don't see private mixins (that don't at least effect the object's v-table) to be very interesting: why not just create and delegate to an object then?
Comments
Oh absolutely, the type enhancement is what makes it so interesting to use, but the point is that it's not necessary for it to be a mixin. It's a very nice extra.
I'm not sure about python, but Ruby completely inlines the mixin's code. It needs to do this because instance variables can be created anywhere, including from inside the mixin, but they still need to apply to the object of the actual class. This gives interesting cases for collisions, where 2 mixins create the same instance variable, but it's a decidedly non-inheritance way of doing it.
I use a mixin pattern extensively in C# that involves an interface to say the object provides a mixin object (C# also provides for partial classes, but its not good enough). Polymorphism is preserved via this method (though all clients delegate through MixX). Actually, I don't see private mixins (that don't at least effect the object's v-table) to be very interesting: why not just create and delegate to an object then?