2

この(不自然な)コードを考えてみましょう:

sealed abstract class MyCaseClass(val num : Long)
case class CaseOne(override val num : Long) extends MyCaseClass(num)
case class CaseTwo(override val num : Long) extends MyCaseClass(num)

val groupedObs : Observable[(Long, Observable[MyCaseClass])] =
    Observable(1 to 20) map {
      x => if (x > 10) CaseOne(x) else CaseTwo(x)
  } groupBy {
    case CaseOne(x) => x % 2 == 0
    case CaseTwo(x) => x % 2 == 0
  }

groupedObs subscribe ( (onNext : (Long,Observable[MyCaseClass])) => onNext match {
        case (even : Boolean, o : Observable[CaseOne] ) => println("Case one")
        case (even : Boolean, o : Observable[CaseTwo] ) => println("Case two")
    }
)

最初の 10 がCaseOneで、次がであるオブザーバブルを作成しますCaseTwo。次に、それらが偶数か奇数かによってグループ化されます。したがって、グループ化されたオブザーバブルはObservable[(Long, Observable[MyCaseClass])]、RX-Java 仕様に従って型になります。

ただし、「groupedby」オブザーバブルをサブスクライブするようになると、タイプの消去は、ネストされたオブザーバブルのシグネチャが失われることを意味します。つまり、それが CaseOne か CaseTwo か ( type になりますAny) - コンパイラーはこれについて警告します。したがって、出力は

Case one
Case one
Case one
...

私の質問は、上記のシナリオで、ネストされた Observable の型消去をどのように処理するのですか?

これまでの私の唯一の回避策は、ネストされた Observable 型を識別するために使用されるキーに追加の値を含めてから、asInstanceこの型に ( を使用して) キャストすることでした。しかし、これはあまりよろしくありません。

また、この例では使用していませんevenが、問題の構造を直接反映していることにも注意してください。

4

1 に答える 1