Przeczytałem kilka artykułów wyrażających, że w celu uzyskania polimorfizmu związanego z F w Scali należy używać typów abstrakcyjnych. Ma to na celu przede wszystkim złagodzenie problemów z wnioskami typu, ale także usunięcie kwadratowego wzrostu, jaki parametry wydają się wprowadzać przy definiowaniu typów rekursywnych.F-Bounded polimorfizm z typami abstrakcyjnymi w Scali
Są one zdefiniowane jako tak:
trait EventSourced[E] {
self =>
type FBound <: EventSourced[E] { type FBound <: self.FBound }
def apply(event: E): FBound
}
to jednak wydaje się wprowadzenie dwóch kwestii:
1) Za każdym razem gdy użytkownik chce odwołać obiekt tego typu, muszą one również dotyczyć parametr typu FBound
. To czuje się jak zapach kod:
def mapToSomething[ES <: EventSourced[E], E](eventSourced: ES#FBound): Something[ES, E] = ...
2) kompilator jest teraz w stanie wywnioskować parametrów typu metod, takich jak powyższe, w przypadku braku z komunikatem:
Type mismatch, expected: NotInferredES#FBound, actual: MyImpl#FBound
Czy ktoś tam przy użyciu udane wdrożenie w swoim rozwiązaniu polimorfizmu związanego z atomem f, w którym kompilator wciąż jest w stanie wnioskować o typach?
Scala zbiory biblioteki korzysta F-ograniczony polimorfizm pomyślnie bez problemów. Używa parametrów typu, a nie członków typu, możesz wypróbować rozwiązanie oparte na tym. – wingedsubmariner
Proszę podać przykład, na który należy zwrócić uwagę, tj. Które części biblioteki to robią? –
Zobacz [List] (http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List) w standardowej bibliotece. Zwróć uwagę na polimorfizm związany z F używany w dziedziczeniu GenericTraversableTemplate i LinearSeqOptimized. – wingedsubmariner