undefined | Better HN

0 pointschton11y ago0 comments

Scala's implementation is definitely an interesting and a valuable one. I'm not debating that inheritance-based mixins are useful, they definitely are. It's just that they aren't necessarily inheritance-based, and there are many implementations of mixins that aren't, so defining it as such is at best somewhat limited and at worst misleading.

On a side note: scala's implementation, internally, is composition-based, since they compile forwarding methods to static methods into the class. They add an interface for those forwarding methods, so it can be used for polymorphism (which is what allows the fun things) but for their system to qualify as mixins, that interface is not necessary. For a very quick reference about this, you can look at http://stackoverflow.com/questions/2557303/how-are-scala-tra...

0 comments

seanmcdirmid11y ago

The type enhancement means that traits could replace classes completely in scala, which is kind of exciting. The problem with traits is that state must be inlined even if implementations are not (so they are a mixture of mixins and small talk style traits). I'm well versed in how they are implemented in scalac.

What non-CL mixins are not inheritance based? Python?

chtonOP11y ago

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.

seanmcdirmid11y ago

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?

j / k navigate · click thread line to collapse

0 pointschton11y ago0 comments

0 comments

seanmcdirmid11y ago

What non-CL mixins are not inheritance based? Python?

chtonOP11y ago

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.

seanmcdirmid11y ago

j / k navigate · click thread line to collapse