What's in a name? {Receive,Send}Channel

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

[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.

[elizarov]

Closing this one. Will not fix.