Pourquoi l'exemple ne se compile-t-il pas, c'est-à-dire comment fonctionne la (co-, contre- et in-) variance?

Suite à cette question , quelqu'un peut-il expliquer ce qui suit dans Scala:

class Slot[+T] (var some: T) { 
   //  DOES NOT COMPILE 
   //  "COVARIANT parameter in CONTRAVARIANT position"

}

Je comprends la distinction entre +Tet Tdans la déclaration de type (elle compile si j'utilise T). Mais alors comment écrire réellement une classe qui est covariante dans son paramètre de type sans recourir à la création de la chose non paramétrée ? Comment puis-je m'assurer que les éléments suivants ne peuvent être créés qu'avec une instance de T?

class Slot[+T] (var some: Object){    
  def get() = { some.asInstanceOf[T] }
}

EDIT - maintenant cela se résume à ce qui suit:

abstract class _Slot[+T, V <: T] (var some: V) {
    def getT() = { some }
}

tout va bien, mais j'ai maintenant deux paramètres de type, où je n'en veux qu'un. Je vais re-poser la question ainsi:

Comment puis-je écrire une classe immuable Slot qui est covariante dans son type?

EDIT 2 : Duh! J'ai utilisé varet non val. Voici ce que je voulais:

class Slot[+T] (val some: T) { 
}

De manière générique, un paramètre de type covariant est un paramètre qui peut varier vers le bas lorsque la classe est sous-typée (en variante, varier avec le sous-typage, d'où le préfixe "co-"). Plus concrètement:

trait List[+A]

List[Int]est un sous-type de List[AnyVal]parce que Intest un sous-type de AnyVal. Cela signifie que vous pouvez fournir une instance de List[Int]quand une valeur de type List[AnyVal]est attendue. C'est vraiment un moyen très intuitif pour les génériques de fonctionner, mais il s'avère qu'il n'est pas sain (casse le système de types) lorsqu'il est utilisé en présence de données mutables. C'est pourquoi les génériques sont invariants en Java. Bref exemple de dysfonctionnement à l'aide de tableaux Java (qui sont à tort covariants):

Object[] arr = new Integer[1];
arr[0] = "Hello, there!";

Nous venons d'attribuer une valeur de type Stringà un tableau de type Integer[]. Pour des raisons qui devraient être évidentes, ce sont de mauvaises nouvelles. Le système de types de Java permet en fait cela au moment de la compilation. La JVM lancera "utilement" un ArrayStoreExceptionat runtime. Le système de type de Scala évite ce problème car le paramètre de type de la Arrayclasse est invariant (la déclaration est [A]plutôt que [+A]).

Notez qu'il existe un autre type de variance appelé contravariance . Ceci est très important car cela explique pourquoi la covariance peut causer certains problèmes. La contravariance est littéralement l'opposé de la covariance: les paramètres varient à la hausse avec le sous-typage. C'est beaucoup moins courant en partie parce qu'il est tellement contre-intuitif, bien qu'il ait une application très importante: les fonctions.

trait Function1[-P, +R] {
  def apply(p: P): R
}

Notez l' annotation de variance " - " sur le Pparamètre de type. Cette déclaration dans son ensemble signifie qu'elle Function1est contravariante dans Pet covariante dans R. Ainsi, nous pouvons dériver les axiomes suivants:

T1' <: T1
T2 <: T2'
---------------------------------------- S-Fun
Function1[T1, T2] <: Function1[T1', T2']

Notez qu'il T1'doit s'agir d'un sous-type (ou du même type) de T1, alors que c'est l'inverse pour T2et T2'. En anglais, cela peut se lire comme suit:

Une fonction A est un sous - type d' une autre fonction B si le type de paramètre A est un supertype du type de paramètre de B pendant que le type de retour de A est un sous - type du type de retour de B .

La raison de cette règle est laissée comme exercice au lecteur (indice: pensez à différents cas car les fonctions sont sous-typées, comme mon exemple de tableau ci-dessus).

Avec vos nouvelles connaissances sur la co- et la contravariance, vous devriez être en mesure de voir pourquoi l'exemple suivant ne se compilera pas:

trait List[+A] {
  def cons(hd: A): List[A]
}

Le problème est que Ac'est covariant, alors que la consfonction s'attend à ce que son paramètre de type soit invariant . Ainsi, Afait varier la mauvaise direction. Il est intéressant de noter que nous pourrions résoudre ce problème en rendant Listcontravariant dans A, mais le type de retour List[A]serait alors invalide car la consfonction s'attend à ce que son type de retour soit covariant .

Nos deux seules options ici sont: a) rendre Ainvariant, en perdant les propriétés de sous-typage intuitives et intéressantes de la covariance, ou b) ajouter un paramètre de type local à la consméthode qui définit Acomme une limite inférieure:

def cons[B >: A](v: B): List[B]

Ceci est maintenant valide. Vous pouvez imaginer que cela Avarie vers le bas, mais Best capable de varier à la hausse par rapport à Apuisque Ac'est sa limite inférieure. Avec cette déclaration de méthode, nous pouvons Aêtre covariants et tout fonctionne.

Notez que cette astuce ne fonctionne que si nous retournons une instance Listdont est spécialisée sur le type moins spécifique B. Si vous essayez de rendre Listmutable, les choses échouent puisque vous finissez par essayer d'attribuer des valeurs de type Bà une variable de type A, ce qui est interdit par le compilateur. Chaque fois que vous avez une mutabilité, vous devez avoir un mutateur quelconque, qui nécessite un paramètre de méthode d'un certain type, ce qui (avec l'accesseur) implique l'invariance. La covariance fonctionne avec des données immuables puisque la seule opération possible est un accesseur, auquel un type de retour covariant peut être attribué.

@Daniel l'a très bien expliqué. Mais pour l'expliquer en bref, si c'était permis:

  class Slot[+T](var some: T) {
    def get: T = some   
  }

  val slot: Slot[Dog] = new Slot[Dog](new Dog)   
  val slot2: Slot[Animal] = slot  //because of co-variance 
  slot2.some = new Animal   //legal as some is a var
  slot.get ??

slot.getlancera alors une erreur au moment de l'exécution car il n'a pas réussi à convertir un Animalen Dog(duh!).

En général, la mutabilité ne va pas bien avec la co-variance et la contre-variance. C'est la raison pour laquelle toutes les collections Java sont invariantes.

Voir Scala par exemple , page 57+ pour une discussion complète à ce sujet.

Si je comprends bien votre commentaire, vous devez relire le passage à partir du bas de la page 56 (en gros, ce que je pense que vous demandez n'est pas de type sécurisé sans vérification du temps d'exécution, ce que scala ne fait pas, vous n'avez donc pas de chance). Traduire leur exemple pour utiliser votre construction:

val x = new Slot[String]("test") // Make a slot
val y: Slot[Any] = x             // Ok, 'cause String is a subtype of Any
y.set(new Rational(1, 2))        // Works, but now x.get() will blow up 

Si vous pensez que je ne comprends pas votre question (une possibilité distincte), essayez d'ajouter plus d'explications / de contexte à la description du problème et j'essaierai à nouveau.

En réponse à votre modification: les machines à sous immuables sont une situation complètement différente ... * sourire * J'espère que l'exemple ci-dessus vous a aidé.

Vous devez appliquer une limite inférieure sur le paramètre. J'ai du mal à me souvenir de la syntaxe, mais je pense que cela ressemblerait à ceci:

class Slot[+T, V <: T](var some: V) {
  //blah
}

La Scala-par-exemple est un peu difficile à comprendre, quelques exemples concrets auraient aidé.