W jaki sposób cechy w Scali unikają „błędu diamentu”?

(Uwaga: Użyłem „błędu” zamiast „problemu” w tytule z oczywistych powodów…;)).

Zrobiłem kilka podstawowych lektur na temat cech w Scali. Są one podobne do interfejsów w Javie lub C #, ale pozwalają na domyślną implementację metody.

Zastanawiałem się: czy nie może to spowodować „problemu z diamentem” i dlatego wiele języków w ogóle unika wielokrotnego dziedziczenia?

Jeśli tak, jak Scala sobie z tym poradzi?

Problem z diamentami polega na niemożności podjęcia decyzji, którą metodę wybrać. Scala rozwiązuje ten problem, określając, którą implementację wybrać jako część specyfikacji językowych ( przeczytaj część o Scali w tym artykule w Wikipedii ).

Oczywiście ta sama definicja porządku może być również stosowana w wielokrotnym dziedziczeniu klas, więc po co zawracać sobie głowę cechami?

Powodem, dla którego IMO jest konstruktorem. Konstruktory mają kilka ograniczeń, których nie mają zwykłe metody - można je wywoływać tylko raz na obiekt, należy je wywoływać dla każdego nowego obiektu, a konstruktor klasy potomnej musi wywołać konstruktor rodzica jako pierwszą instrukcję (większość języków będzie zrób to dla ciebie niejawnie, jeśli nie musisz przekazywać parametrów).

Jeśli B i C odziedziczą A i D, odziedziczą B i C, a oba konstruktory B i C wywołują konstruktor A, wówczas konstruktor D wywoła konstruktor A dwa razy. Definiowanie których implementacje wybrać jak Scala zrobił z metody nie będą działać tutaj, ponieważ oba muszą być nazywane B i konstruktorzy c za.

Cechy unikają tego problemu, ponieważ nie mają konstruktorów.

Scala unika problemu diamentów przez coś, co nazywa się „linearyzacją cechy”. Zasadniczo sprawdza implementację metody w cechach rozszerzanych od prawej do lewej. Prosty przykład:

trait Base {
   def op: String
}

trait Foo extends Base {
   override def op = "foo"
}

trait Bar extends Base {
   override def op = "bar"
}

class A extends Foo with Bar
class B extends Bar with Foo

(new A).op
// res0: String = bar

(new B).op
// res1: String = foo

To powiedziawszy, lista cech, które wyszukuje, może zawierać więcej niż te, które wyraźnie podałeś, ponieważ mogą one rozszerzyć inne cechy. Szczegółowe wyjaśnienie znajduje się tutaj: cechy jako modyfikacje, które można ustawiać jeden na drugim, i bardziej kompletny przykład linearyzacji: dlaczego nie wielokrotne dziedziczenie?

Wierzę, że w innych językach programowania takie zachowanie jest czasem określane jako „Kolejność rozwiązywania metod” lub „MRO”.