Kotlinx.coroutines: What's in a name? {Receive,Send}Channel

[venkatperi]

fun idiomHasher() : ReceiveChannel<String> //=>

"Color me a nitpicker"
"A rose by any other moniker..."

So we receive data from a ReceiveChannel and send data to a SendChannel. Simple? Not really.

Even after some experience with channels, I'm struggling with the names. The train of thought is along these lines:

• "I want to read from the channel; what was the name of the readable interface? er.. hm.. receive... oh yeah, ReceiveChannel". Same with SendChannel.

• Or more commonly, "I have a ReceiveChannel. So, is that something I receive from, or does it receive from me?". Less so for SendChannel.

I guess the issue here is while Receive and Send are behaviors (and behaviors are decent way to name interfaces), they are not specific enough.

IMHO, names that less ambigious:

• Readable{Sumethin'} tells me I can read from it vs. Writable{Sumthin'}. (NodeJS)

• Output{YourFavoriteCommunicationOrificeHere} tells me I must read from it, and vice versa with Input{YFCOH} (DirectShow filters; yes I am dated).

Regarding whether {Receive,Send}Channel are channels, or something else: according to Merriam-Webster, a channel is --

a means of communication or expression: such as (1) : a path along which information (such as data or music) in the form of an electrical signal passes.

So it would seem that Channel<E> is appropriately named. However {Receive,Send}Channel are interfaces to Channel where data can hop on or off the channel and as such, they are not channels. Nautical terms that define such a concept include pier, dock, jetty, and port among others.

IMHO, {Receive,Send}Channel should be renamed to:

• {Receive,Send}Port
• Or better still {Output,Input}Port

[elizarov]

It is an interesting observation. I am not entirely convinced a name change would help here, though. It looks like we are just missing some better (and more indepth) explanations concerning channel in particular. The current treatment of channel in the guide is at best cursory.

Note, that the naming of channels this way is modeled after channels in Go language, which seems to work well there: https://golang.org/ref/spec#Channel_types

[fvasco]

I reuse this thread for a personal observation: often permissions are readable, writable and so on, but a SendChannel is writable if it not isClosedForSend, and a ReceiveChannel is accessible if it not isClosedForReceive, so I often use this double negation in my code.

My suggestion is use the positive version, like isOpenForSend or isOpenForReceive, or something similar like canSend or canReceive.

[SolomonSun2010]

Cool, Dart lang have the {Receive,Send}Port :
https://api.dartlang.org/stable/2.0.0/dart-isolate/ReceivePort-class.html

and have the sync,sync,async,async,yield,yield* ......
@elizarov

[elizarov]

Closing this one. Will not fix.

[joffrey-bion]

I find it funny to note that the "names that are less ambigious" actually tricked you @venkatperi :

Output{YourFavoriteCommunicationOrificeHere} tells me I must read from it

This is wrong. We read from InputStreams, and write to OutputStreams.

These names are not that bad after all I believe, even for someone that is not used to them.