Scala - pattern-matching d'un n-uplet de types

J'ai la classe suivante hiérarchie:

class A
class B extends A
class C extends A

puis, il y a une autre classe qui prend des instances de ces classes et il y a une méthode, dans lequel les deux cas de pattern-matching sont possibles comme ceci:

class D (one: A, two: A) {

  def work {
    (one, two) match {
      case (o, t): (B, B) => ... blablabla
      case (o, t): (B, C) => ... blablabla
      case _ =>
    }
  }
}

Cependant, lorsqu'il doit résoudre la mise en correspondance en faveur du second cas (B, C), il essaie de le résoudre comme (B, B) et vient à la classe de fonte sauf que C cannot be cast to B. Pourquoi? Que faire? Comment puis-je contourner cela?

InformationsquelleAutor noncom | 2012-08-16
  1. 29

    Votre syntaxe n'est pas tout à fait bon (ne compile pas).

    Cela fonctionne bien:

    object Matcher extends App {

  class A
  class B extends A
  class C extends A

  class D(one: A, two: A) {

    def work {
      (one, two) match {
        case (o: B, t: B) => println("B")
        case (o: B, t: C) => println("C")
        case _ =>
      }
    }
  }

  val d1 = new D(new B, new B)
  val d2 = new D(new B, new C)

  d1.work
  //B
  d2.work
  //C
}
    InformationsquelleAutor Brian Smith
  2. 8

    Le problème, comme toujours, est effacée types. (B,C) est sucre syntaxique pour Tuple2[B,C], qui est effacée à Tuple2 au moment de l'exécution. L'instruction de cas, vérifie que (B,C) correspond Tuple2, mais ne parvient pas à jeter.

    Dans votre cas, la solution la plus simple serait de match contre le " un " et "deux" individuellement, plutôt que de les envelopper dans un tuple:

    one match {
  case o : B => two match {
    case p : C => ...
    case p : B => ...
  }
  ... 
}

    Il n'est pas si jolie, mais il ne souffre pas du même problème.

    Edit: en Fait, j'irais avec Brian Smith solution correspondant à l'intérieur de la n-uplet plutôt qu'à l'extérieur. Il permet d'éviter le problème d'une manière similaire, mais ressemble plus belle.

    InformationsquelleAutor Submonoid
  3. 2

    J'ai fait ce code de travail.

    Tout d'abord, j'ai ajouté un cas à la définition de classe.

    case class A
case class B extends A
case class C extends A

    Deuxièmement, j'ai changé le work.

    class D(one: A, two: A) {
  def work {
    (one, two) match {
      case (o: B, t: B) => println("BB")
      case (o: B, t: C) => println("BC")
      case (o: C, t: C) => println("CC")
      case _ => println("AA")
    }
  }
}

    Maintenant ce que j'ai:

    new D(B(),B()).work      => BB
new D(B(),C()).work      => BC
new D(C(),C()).work      => CC
new D(A(),B()).work      => AA

    La case ajoute une applique et une délettrer méthode.

    • Ouais, des classes de cas... mais ils ont des bugs avec l'héritage.. je serai très heureux si ils fixent parfois des...
    • Je suis totalement avec vous.
    • Ce code ne compile pas moderne Scala, parce que les cas d'héritage est interdite depuis de 2,9 je pense. @noncom Ce n'est pas un bug, c'est voulu par la conception
    • J'ai copié ce code à partir de la REPL (Scala 2.9.1). Il n'a compiler.
    • Pas sans mises en garde, j'en suis sûr. En Scala 2.10 cela ne compile pas
    • non, en fait je m'en souviens très bien leur disant que la mise en œuvre correcte de l'héritage est très difficile en raison de problèmes techniques avec le compilateur et de la JVM ou quelque chose comme ça et le contemporal mise en œuvre contenues bugs, c'est à dire "l'utilisation à vos propres risques, il peut fonctionner ou il peut se casser". Idk quelle manière les choses se sont la prochaine, peut-être qu'ils ont explicitement interdit ce genre d'héritage.. parce que j'ai laissé tomber Scala il y a quelques années et s'est totalement Clojure.

    InformationsquelleAutor tgr