Comment définir la "disjonction de types" (union de types) ?

Question

Un moyen qui a a été suggéré pour traiter les doubles définitions de méthodes surchargées est de remplacer la surcharge par le pattern matching :

object Bar {
   def foo(xs: Any*) = xs foreach { 
      case _:String => println("str")
      case _:Int => println("int")
      case _ => throw new UglyRuntimeException()
   }
}

Cette approche exige que nous abandonnions la vérification statique des types sur les arguments à foo . Il serait beaucoup plus agréable de pouvoir écrire

object Bar {
   def foo(xs: (String or Int)*) = xs foreach {
      case _: String => println("str")
      case _: Int => println("int")
   }
}

Je peux m'approcher avec Either mais cela devient vite moche avec plus de deux types :

type or[L,R] = Either[L,R]

implicit def l2Or[L,R](l: L): L or R = Left(l)
implicit def r2Or[L,R](r: R): L or R = Right(r)

object Bar {
   def foo(xs: (String or Int)*) = xs foreach {
      case Left(l) => println("str")
      case Right(r) => println("int")
   }
}

Il semble qu'une solution générale (élégante, efficace) nécessiterait de définir Either3 , Either4 , .... Quelqu'un connaît-il une autre solution pour atteindre le même objectif ? À ma connaissance, Scala n'a pas de "disjonction de type" intégrée. De plus, les conversions implicites définies ci-dessus se cachent-elles quelque part dans la bibliothèque standard pour que je puisse simplement les importer ?

Answer 1

Miles Sabin décrit une très belle façon d'obtenir le type d'union dans son récent billet de blogue Types d'union sans boîte en Scala via l'isomorphisme de Curry-Howard :

Il définit d'abord la négation des types comme

type ¬[A] = A => Nothing

en utilisant la loi de De Morgan, cela lui permet de définir des types d'union

type [T, U] = ¬[¬[T] with ¬[U]]

Avec les constructions auxiliaires suivantes

type ¬¬[A] = ¬[¬[A]]
type ||[T, U] = { type [X] = ¬¬[X] <:< (T  U) }

vous pouvez écrire des types d'union comme suit :

def size[T : (Int || String)#](t : T) = t match {
    case i : Int => i
    case s : String => s.length
}

Answer 2

Eh bien, dans le cas spécifique de Any* l'astuce ci-dessous ne fonctionnera pas, car elle n'accepte pas les types mixtes. Cependant, comme les types mixtes ne fonctionnent pas non plus avec la surcharge, c'est peut-être ce que vous voulez.

Tout d'abord, déclarez une classe avec les types que vous souhaitez accepter comme ci-dessous :

class StringOrInt[T]
object StringOrInt {
  implicit object IntWitness extends StringOrInt[Int]
  implicit object StringWitness extends StringOrInt[String]
}

Ensuite, déclarez foo comme ça :

object Bar {
  def foo[T: StringOrInt](x: T) = x match {
    case _: String => println("str")
    case _: Int => println("int")
  }
}

Et c'est tout. Vous pouvez appeler foo(5) o foo("abc") et cela fonctionnera, mais essayez foo(true) et il échouera. Le code client peut contourner ce problème en créant un fichier de type StringOrInt[Boolean] sauf si, comme indiqué par Randall ci-dessous, vous faites StringOrInt a sealed classe.

Cela fonctionne parce que T: StringOrInt signifie qu'il y a un paramètre implicite de type StringOrInt[T] et parce que Scala regarde à l'intérieur des objets compagnons d'un type pour voir s'il y a des implicites pour faire fonctionner le code qui demande ce type.

Answer 3

Voici la méthode de Rex Kerr pour coder les types d'union. C'est simple et direct !

scala> def f[A](a: A)(implicit ev: (Int with String) <:< A) = a match {
     |   case i: Int => i + 1
     |   case s: String => s.length
     | }
f: [A](a: A)(implicit ev: <:<[Int with String,A])Int

scala> f(3)
res0: Int = 4

scala> f("hello")
res1: Int = 5

scala> f(9.2)
<console>:9: error: Cannot prove that Int with String <:< Double.
       f(9.2)
        ^

---

Source : Commentaire n° 27 sous este excellent article de blog de Miles Sabin qui fournit une autre façon d'encoder les types d'union en Scala.

Answer 4

Il est possible de généraliser La solution de Daniel comme suit :

sealed trait Or[A, B]

object Or {
   implicit def a2Or[A,B](a: A) = new Or[A, B] {}
   implicit def b2Or[A,B](b: B) = new Or[A, B] {}
}

object Bar {
   def foo[T <% String Or Int](x: T) = x match {
     case _: String => println("str")
     case _: Int => println("int")
   }
}

Les principaux inconvénients de cette approche sont les suivants

• Comme Daniel l'a souligné, il ne gère pas les collections/varargues avec des types mixtes.
• Le compilateur n'émet pas d'avertissement si la correspondance n'est pas exhaustive.
• Le compilateur n'émet pas d'erreur si la correspondance inclut un cas impossible.
• Comme le Either approche, une généralisation plus poussée nécessiterait de définir des modèles analogues. Or3 , Or4 etc. Bien entendu, il serait beaucoup plus simple de définir de tels traits que de définir les caractères correspondants. Either classes.

Mise à jour :

Mitch Blevins démontre une approche très similaire et montre comment le généraliser à plus de deux types, en le surnommant le "bégaiement ou".

Answer 5

Une solution de classe de type est probablement la plus belle façon de procéder ici, en utilisant des implicites. Cette approche est similaire à celle des monoïdes mentionnée dans le livre d'Odersky/Spoon/Venners :

abstract class NameOf[T] {
  def get : String
}

implicit object NameOfStr extends NameOf[String] {
  def get = "str"
}

implicit object NameOfInt extends NameOf[Int] {
 def get = "int"
}

def printNameOf[T](t:T)(implicit name : NameOf[T]) = println(name.get)

---

Si vous exécutez ensuite ceci dans le REPL :

scala> printNameOf(1)
int

scala> printNameOf("sss")
str

scala> printNameOf(2.0f)
<console>:10: error: could not find implicit value for parameter nameOf: NameOf[
Float]
       printNameOf(2.0f)

              ^