How are Scala's traits not really traits?

Question

Someone recently told me that Scala's traits aren't "true" traits, and that they were really just mixins. Unfortunately, I didn't get the opportunity to ask him why. Does anyone have an idea what he meant?

Edit: As a definition of "traits," I have been referring to Nathanael Schärli’s dissertation and concept paper introducing traits. One key feature that seems to be missing from most mixin and/or multiple inheritance implementations is the ability to rename methods when you import them to avoid collision/ambiguity. Can Scala do that?

Answer 1

I think that probably has to do with what's in Scala as opposed to what was proposed in the original paper.

I once thought about this question too, implementation differences aside, I've come to the conclusion that traits in Scala indeed left something to be desired. The way that Scala let you compose but not exclude methods is strange. To avoid conflicts, it had borrowed something called a method resolution order (or linearization in Scala-speak) from other languages. There's a problem well-known for languages that support multiple-inheritance, which I will boldly classify Scala as a member of this group. The problem is that it's too complicated and time-consuming to understand.

Scala's method resolution order is a strange beast, it has its own algorithm for method dispatch. It's not Dylan's C3, which is used in Python, with some notable problems, but has all the problems that are associated with it. Worse, I can look up a Python object's MRO by calling its .mro() method. There's no equivalent in Scala.

I can tell you I'm not very fond to running the Scala MRO algorithm in my head for every time I need to look up where a method will be resolved to.