How are Scala traits not character traits?

Question

Someone recently told me that Scala traits are not “true” traits and that they are really just mixins. Unfortunately, I did not have the opportunity to ask him why. Does anyone have an idea of ​​what he meant?

Edit: As a definition of “traits,” I meant the dissertation and the concept paper Nathanael Schärlis

Answer 1

One key that differs between mixins and traits is that mixins have fields, while traits do not. To paraphrase the original paper, a symptom:

• provides methods that implement behavior
• requires methods that parameterize the provided behavior
• do not indicate or access any fields
• symmetrically composed
• may be nested equivalent to smoothed features

At first glance, the third point looks as if it was violated in the implementation of Scala. However, traits can only access public fields that are protected by implicit getters and setters. The rest of the document describes that this is acceptable for implementing features.

You note that a key feature of the features is that methods can be renamed upon import. This is not possible given the limitations of the JVM. A consistent discussion of this issue can be found here: http://scala-programming-language.1934581.n4.nabble.com/Trait-method-aliasing-td2322026.html , especially David Pollack's posts.

Finally, my answer to your general question is “kinda”. To clarify, while Scala traits are not strictly traits defined in the document, they are also not strictly mixins. In any case, it is probably best to use them, as they were traits, and stick to your design principles.

• Keep them small for reuse.
• Indicate the behavior is not able to.

Answer 2

I think this is probably due to what was in Scala, in contrast to what was suggested in the original article.

I also thought about this issue, differences in implementation, I came to the conclusion that the features in Scala really leave much to be desired. It is strange that Scala allows you to create, but not exclude, methods. To avoid conflicts, he borrowed something called a resolution method (or linearization in Scala -speak) from other languages. There the problem is well known for languages ​​that support multiple inheritance, which I boldly classify Scala as a member of this group. The problem is that it is too complicated and takes a lot of time to understand.

Scala order resolution order is a strange beast, it has its own algorithm for sending a method. This is not Dylan C3, which is used in Python, with some known problems , but has all the problems associated with it. Even worse, I can find the Python object's MRO object by calling its .mro() method. Scala has no equivalent.

I can say that I do not really like to run the Scala MRO algorithm in my head for every time I need to look for where the method will be resolved.

Answer 3

No, Scala cannot be renamed upon import.

I wonder how it will work. If the method m attribute T renamed to m2 in the object o , how would pm be allowed if p is a parameter of type T and o passed through this?