Różnica między cecha dziedziczenia i rodzaju własnej adnotacji

Question

w Scala, widziałem konstrukty

trait T extends S 

i

trait T { this: S => 

wykorzystane do osiągnięcia podobnych rzeczy (a mianowicie, że abstrakcyjne metody S musi być zdefiniowane przed utworzeniem instancji). Jaka jest między nimi różnica? Dlaczego używałbyś jednego nad drugim?

Answer 1

Używałbym self-types do zarządzania zależnościami: Ta cecha wymaga mieszania innej cechy. I użyłbym dziedziczenia do udoskonalenia innej cechy lub interfejsu.

Tylko jako przykład:

trait FooService 

trait FooRemoting { this : FooService => } 
trait FooPersistence { this : FooService => } 

object Services extends FooService with FooRemoting with FooPersistence 

Teraz, jeśli FooRemoting i FooPersistence zarówno byłby odziedziczone FooService i FooService ma członków i sposobów, w jaki sposób usługi wyglądać?

Podczas gdy dla dziedziczenia, musielibyśmy coś takiego:

trait Iterator[T] { 
    def hasNext : boolean 
    def next : T 
} 

trait InfiniteIterator[T] extends Iterator[T] { 
    def hasNext = true 
} 

Answer 2

zaworem adnotacje pozwalają wyrazić zależności cykliczne. Na przykład:

trait A extends B 
trait B { self: A => } 

Nie jest to możliwe przy prostym dziedziczeniu.

Answer 3

Ponieważ zadajesz pytanie natknąłem tych stanowisk:

Spiros Tzavellas rozmowy o użyciu cechę jak interfejsie publicznym i typu siebie jako pomocnik, które muszą być zmieszane w przez klasę realizacji.

Podsumowując, jeśli chcemy przenieść implementacje metod wewnątrz cech wtedy ryzykujemy zanieczyszczających interfejs tych cech z abstrakcyjnych metod które wspierają realizację konkretnych metod i niezwiązane z głównym odpowiedzialność za cechę . Rozwiązaniem tego problemu jest przeniesienie tych abstrakcyjnych metod w inne cechy i skomponowanie ich razem przy użyciu adnotacji typu self i wielokrotnego dziedziczenia.

Na przykład:

trait PublicInterface { this: HelperTrait => 
    // Uses helperMethod 
} 

trait HelperTrait { 
    def helperMethod = // ... 
} 

class ImplementationClass extends PublicInterface with HelperTrait 

A Tour of Scala omawia użycie zaworem adnotacje z abstrakcyjnych elementów typu - przypuszczalnie nie jest możliwe do extend streszczenie członkiem typ

Answer 4

Chociaż nie odpowiada (?) Twoje pytanie, starałem się zrozumieć adnotacje typu self i zasadniczo zagubiłem się w odpowiedziach, i jakoś skończyłem na cyklach poprzez różne warianty twojego pytania, które koncentrują się na używaniu adnotacji self-type do opisywania zależności.

Więc tutaj zamieścić opis danego przypadku użycia gdzie jaźń typu adnotacje są dobrze ilustrowany, czyli coś podobnego przypadku type-safe z „tym” jako podtyp:

http://programming-scala.labs.oreilly.com/ch13.html#SelfTypeAnnotationsAndAbstractTypeMembers

nadzieję, że Byłoby to pomocne dla tych, którzy przypadkowo trafiają na to pytanie (i, tak jak ja, nie mieli czasu na przeczytanie książki o scali przed rozpoczęciem eksploracji :-))

Answer 5

Odpowiedź brzmi "okrągłość". Ale nie tylko.

Adnotacja typu self rozwiązuje dla mnie podstawowy problem dziedziczenia: to, z czego odziedziczysz, nie może używać tego, czym jesteś. Dzięki samemu typowi wszystko staje się łatwe.

mój wzór jest następujący i można go traktować jako zdegenerowanego ciasto:

trait A { self: X => def a = reuseme} 
trait B { self: X => def b = a } 
class X extends A with B { def reuseme=null } 

Możesz wybuchnąć klasę w wielu zachowań, które mogą być wywoływane z dowolnego miejsca w zespole, podczas pobytu czysto wpisane. Nie trzeba zbyt często bolesnego kierowania (i niesłusznie) identyfikować z wzorcem ciasta.

Połowa (jeśli nie całość) zawiłych frameworków Java DI z ostatnich dziesięciu lat została poświęcona temu procesowi, oczywiście bez pisania. Osoby wciąż używające JAVA w tej domenie wyraźnie tracą swój czas: "SCALA ouakbar".