Need new names for { input, output }

[domenic]

Originally raised in sysapps/tcp-udp-sockets#69.

My thinking has been that you write things in to the input (a writable stream), and you read them out of the output (a readable stream).

Apparently this is at odds with most other programming libraries, for which you write to output and read from input. Unix stdin/stdout is an example, but also some Java stream APIs.

We could just switch them, and that's my fallback position. I am curious if there is a better name pair.

[domenic]

Remember these show up in two places:

1. In the definition of pipeThrough, as in readable.pipeThrough(transform).pipeTo(writable). As defined right now, that is sugar for readable.pipeTo(transform.input); transform.output.pipeTo(writable). So this impacts what transform streams look like when you want to inspect their ends directly or construct one manually.
2. For people setting up non-transform duplex streams, like stdin/stdout (note the confusion) or the TCP/UDP socket cases. For these cases it's just a matter of settling on a convention and in theory every spec or package could choose differently without real problems.

In reality these cases kind of blend together. E.g. you may normally think of a web worker as a duplex stream, for which the two sides are disconnected (kind of like a child process). So in theory this decision doesn't matter for them, right?

And that might normally be true, except what if you are using a web worker to implement a transcoding algorithm? If web workers used the conventional properties recognized by pipeThrough, then people could do readable.pipeThrough(webWorker).pipeTo(writable).

[domenic]

@substack suggests { writer, reader }. So transform.writer.write(chunk) and chunk = transform.reader.read(). Seems nice and simple and not-confusing. Going to go with this unless we get some amazing ideas by tomorrow.

[domenic]

Also in the running { writable, readable }

[yocontra]

My vote is on { writable, readable } - writer and reader are the opposite of what this is

[domenic]

Lots of "this actually means the opposite of what you think" regarding these properties... @_@

[ghost]

The confusion stems from perspective and is somewhat unavoidable because streams are meant to be plumbled together such that the output of one stream is the input of the next.

[chrisdickinson]

I proposed "ingress" and "egress". I tried to pick words that create an unambiguous gradient -- data goes into the ingress, and comes out of the egress. I'm also okay with "readable" and "writable", for similar reasons, though they might run into the perspective problem -- an author of a function that creates a duplex stream pair has to view "readable" as where data will be written to, and "writable" as the side that accepts incoming data.

[gx0r]

I have heard { source, sink } used or { faucet, sink }. Plus it fits in the streams/pipe metaphor :-)

writable: It can write...or one can write to it?
readable: it can read...or one can read from it? Confusing.

[calvinmetcalf]

• {white, black} (analogy to black holes and white holes)
• {emitter, listener} (analogy to events)
• {giver, receiver/taker}

my vote would be { writable, readable } as its clear its based on capability not role

[yocontra]

@llambda I don't think it's confusing at all. If you have a book that is readable, you know you can read from it. If you have a piece of paper that is writable, you know you can write on it

[ferasm]

I'm a bit late, but slowly catching up on things now. I also personally liked writeable/readable, and think the changes look good and also read well. Also slightly follows how the Windows Runtime speaks about streams, so there is some precedence.