I\'m going a little crazy here. I\'m trying to create an Observable
extension function (against RxJava 2.x) to emit the average of the emissio
Type inference mostly does not work for rxJava2. It's not a type inference problem actually. Kotlin usually generates extension methods to that replaces SAM with kotlin functional types, but this technic does not work for overridden methods for some reason.
More details here https://youtrack.jetbrains.com/issue/KT-13609
As an option, you could try to specify types for lambda arguments
fun Observable<BigDecimal>.average() = publish().autoConnect(2).let {
Single.zip(it.sum().toSingle(), it.count(), BiFunction {
sum: BigDecimal, count: Long ->
sum / BigDecimal.valueOf(count)
})
}
Type inference is failing for some reason, there must be somehow multiple combinations of types that could be inferred in this context.
You can specify the types explicitly with a more traditional (and unfortunately more verbose) syntax, like this:
fun Observable<BigDecimal>.average() = publish().autoConnect(2).let {
Single.zip(it.sum().toSingle(), it.count(), BiFunction<BigDecimal, Long, BigDecimal> {
sum, count ->
sum / BigDecimal.valueOf(count)
})
}
Update:
I've just found out while working on a similar problem that the actual problem here is that Kotlin isn't able to infer which Single.zip
overload you're trying to call. From the official documentation:
If the Java class has multiple methods taking functional interfaces, you can choose the one you need to call by using an adapter function that converts a lambda to a specific SAM type. Those adapter functions are also generated by the compiler when needed.
So it turns out that using the more explicit SAM constructor solves this in itself, and gives you type inference back (basically, my previous answer was using a longer syntax than was actually required):
fun Observable<BigDecimal>.average(): Single<BigDecimal> = publish().autoConnect(2).let {
Single.zip(it.sum().toSingle(), it.count(), BiFunction {
sum, count ->
sum / BigDecimal.valueOf(count)
})
}
If type inferencing is the problem, one thing you can do is use RxKotlin
implementation "io.reactivex.rxjava2:rxkotlin:$rxKotlinVersion"
RxKotlin specifically provides SAM helpers to help mitigate the issues with type inferencing issues.
In which case,
Singles.zip(..., ...)
would be able to work just fine without any ambiguity. Notice I am using Singles
and not Single