Menu
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?
999
Traits are used to share interfaces and fields between classes. They are similar to Java 8's interfaces. Classes and objects can extend traits, but traits cannot be instantiated and therefore have no parameters.
Trait supports multiple inheritance. Abstract Class supports single inheritance only. Trait can be added to an object instance. Abstract class cannot be added to an object instance.
We can extend from multiple traits, but only one abstract class. Abstract classes can have constructor parameters, whereas traits cannot.
Delta Lake with Apache Spark using Scala A trait encapsulates method and field definitions, which can then be reused by mixing them into classes. Unlike class inheritance, in which each class must inherit from just one superclass, a class can mix in any number of traits.
Traits can have methods(both abstract and non-abstract), and fields as its members.
In scala, trait is a collection of abstract and non-abstract methods. You can create trait that can have all abstract methods or some abstract and some non-abstract methods. A variable that is declared either by using val or var keyword in a trait get internally implemented in the class that implements the trait.
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.
51
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
