What’s the reasoning that `Channel<T>` and `...
# coroutines
z
What’s the reasoning that
Channel<T>
and
Flow<T>
don’t share the same backing interface? It seems unfortunate that the two won’t be able to share the same operators
e
What do you think they have in common and what operations this interface shall support?
z
You originally stated that one of the goals was that they would both share the same interface so an operator for one would work for the other. I would imagine that you guys encountered a good reason as to why you decided to reverse course on it - was just curious what that reason is
The common theme is both
Channel<T>
and
Flow<T>
are that they both emit values of
T
. The implementation detail is how they emit values
a
Flow does not emit anything, it accepts consumer.
z
Sure, but as a user of the API, I see both
Flow<T>
and
Channel<T>
as a way to consume multiple values of
T
over time
l
You mean
Flow
and
ReceiveChannel
. They are still different as consuming or iterating a channel doesn't share the scope with the producer (and the produced may not even be in a coroutine at all), while a
Flow
collecting coroutine will share its scope with the emitting collector, passing any failures through. Also, a
Flow
emitting collector can always throttle the collecting coroutine, which is not the case for
Channel
.
👍 1
z
oh yeah, my bad.
Flow<T>
and
ReceiveChannel<T>
, not
Channel<T>
e
We came to think they are too different to share an interface. Channels are single use, hot, and must be consumed, while flows are multi-use and cold. So you need to be explicit when converting them using
asFlow()
.
👍 1
l
@elizarov There's no
asFlow()
extension for
ReceiveChannel
as of kotlinx.coroutines 1.2.1
p
There is
asFlow()
on
BroadcastChannel
e
asFlow() = flow { consumeEach { emit(it) } }
l
Sure, and crazy how simple it is, but is there a reason it is not in kotlinx.coroutines?
e
Name and contract. What happens if you do it multiple times? Shall it be named
consumeAsFlow
? Etc....
👍 1