Escriba Members and Covariance

Question

Supongo que "tipo anotaciones de varianza" (+ y -) no se puede aplicar a "tipo miembros". Con el fin de explicar a mí mismo que yo consideraba la siguiente example

abstract class Box {type T; val element: T}

Ahora bien, si quiero crear la clase StringBox tengo que extiendenBox:

class StringBox extends Box { type T = String; override val element = ""}

Por lo tanto, se puede decir que Box es naturalmente covariante en el tipo T. En otras palabras, las clases con miembros de tipo son covariantes en esos tipos.

¿Tiene sentido?
¿Cómo describirías la relación entre los miembros de tipo y la varianza de tipo?

Answer 1

La casilla es invariable en su tipo T, pero eso no significa que no haya nada que ver.

abstract class Box { 
    type T 
    def get: T 
} 
type InvariantBox = Box { type T = AnyRef } 
type SortofCovariantBox = Box { type T <: AnyRef } 

Lo que altera la situación de varianza es el grado en que el tipo está expuesto y la forma en que se hace. Los tipos abstractos son más opacos. Pero deberías jugar con estos problemas en el repl, es bastante interesante.

# get a nightly build, and you need -Ydependent-method-types 
% scala29 -Ydependent-method-types 

abstract class Box { 
    type T 
    def get: T 
} 
type InvariantBox = Box { type T = AnyRef } 
type SortofCovariantBox = Box { type T <: AnyRef } 

// what type is inferred for f? why? 
def f(x1: SortofCovariantBox, x2: InvariantBox) = List(x1, x2) 

// how about this? 
def g[U](x1: Box { type T <: U}, x2: Box { type T >: U}) = List(x1.get, x2.get) 

Y etc.