Quel est l'avantage de définir contains comme contains[BB >: B](e: BB): Boolean au lieu de contains(e: Any): Boolean dans Scala.Avantage de `contient [BB>: B] (e: BB): Boolean` au lieu de` contains (e: Any): Boolean`
Either.contains dans la bibliothèque standard Scala utilise la première signature et je ne suis pas clair sur le bénéfice d'une telle signature sur la deuxième signature.
Dans ce cas, aucune: les deux signatures sont équivalentes. Mais il assure la cohérence avec les signatures d'autres membres tels que
getOrElse[BB >: B](or: ⇒ BB): BB
Pour eux, il y a une différence parce que BB fait partie du type de retour, donc si nous passons un B, nous rentrerons B, que nous n » J'ai avec getOrElse(or: => Any): Any.
Ce qui me rechigne est pourquoi vous voulez jamais passer quelque chose qui est pas un B à cette fonction
Vous ne voudriez pas. Mais contains(e: B) ne permettrait pas de Either d'être covariant. Essayez-le, le compilateur le rejettera au motif que B apparaît dans une position contravariant. La covariance signifie que, par ex. Either[A, SubtypeOfFoo] est un sous-type de Either[A, Foo]. Donc, tout appel qui est légal pour Either[A, Foo] doit être également légal pour Either[A, SubtypeOfFoo], et cela inclut .
type sécurité. passer quelque chose qui n'est pas BB>: B va échouer au moment de la compilation –
@MrD Je suppose que la question est _how_, vous pouvez passer quelque chose qui n'est pas une superclasse de 'B'. Tout est 'Any', et' Any' est une superclasse de 'B' ... Il n'y a pas de type, que cette fonction n'accepte pas AFAICS. – Dima
vous ne pouvez pas passer quelque chose qui n'est pas une superclasse de B, c'est le genre de point. Donc, fondamentalement, pas de sous-types de B. Je pense que la raison en est parce qu'il doit y avoir un bien défini == dans B qui peut être utilisé pour la comparaison –