Add IO::Stapled

[straight-shoota]

Adds IO::Stapled class which staples together two unidirectional IOs to form a single bidirectional IO. It basically delegates all read methods to reader and all write methods to writer.

This class is an extension to unidirectional IOs (like IO::Memory, IO.pipe) when you need true bidirectional IOs, for example as a replacement for socket streams.

This is particularly useful for speccing code that would normally work with a socket. You don't need to create an actual socket but can just staple together two IO::Memory.

[RX14]

also perhaps delegate gets too

[RX14]

IO.pipe will work on windows after we merge #5623, so might as well not have this check

[straight-shoota]

Added gets delegator and removed win32 check 👍

[jhass]

"endpoints"

[asterite]

I would use another example, maybe using two IO::Memory. When I first saw this I thought "why not use IO.pipe directly?".

[ysbaddaden]

Is there any use case other than "mocking sockets in specs"?

[RX14]

Is there any use to IO::Delimited other than HTTP::Multipart :)

I'd be interested in other usages, but I think this is worth it just for the speccing.

[straight-shoota]

@ysbaddaden You could for example wrap the standard streams with HTTP or any other protocol that expects read and write on the same IO ;)

[ysbaddaden]

At least IO::Delimited has a use case in the stdlib. I question here the actual need for IO::Stapled aside from specs, that could just use sockets.

I can appreciate the idea of IO::Stapled, but I fail to fathom actual use cases :(

[asterite]

@ysbaddaden I think the idea is to use it for specs, to stub a socket. But if we are going to do that, maybe IO::Stapled should just have two IO::Memory internally, and maybe be called IO::Mock or something like that.

[straight-shoota]

Yes, the main purpose of this is obviously mocking socket connections, but it can also be generally useful for multiplexing two unidirectional read/write streams in one IO.

Limiting to IO::Memory won't do because you can't really communicate through it. This would limit the usefulness as replacement for socket connections. For many use cases you'll need a pipe (hence there is also a class method to set that up).

[asterite]

Hm, maybe wrapping two pipes is a good use case...