この(不自然な)コードを考えてみましょう:
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
が、問題の構造を直接反映していることにも注意してください。