Fair enough. Thanks again.
On Sat, Oct 4, 2014 at 11:49 AM, Stuart Sierra m...@stuartsierra.com
wrote:
On Sat, Oct 4, 2014 at 12:31 AM, Brian Guthrie btguth...@gmail.com
wrote:
But I'm troubled by the idea of accepting channels as arguments, even
though there's a lot to be said for
On Sat, Oct 4, 2014 at 12:31 AM, Brian Guthrie btguth...@gmail.com wrote:
But I'm troubled by the idea of accepting channels as arguments, even
though there's a lot to be said for consumer control of buffer sizes (to
say nothing of providing potential fakes for test purposes). In that
Hi all,
I'm assembling a library for working with sockets asynchronously (both as a
server and a client) and was wondering if there was a widely-accepted way
of handling channels. The rough idea is that each socket gets two channels,
in and out, receiving data in the former and using the latter
You generally provide more power and flexibility to consumers by handing
them channels. That way the consumer can use things like transducers and
pipelines.
For maximum flexibility, allow the consumer to *pass in* the channels to be
used for input / output. That way the consumer gets to decide
Thanks for the feedback! I buy that direct access to the channels provides
more transformative power, so I'll stick with that. But I'm troubled by the
idea of accepting channels as arguments, even though there's a lot to be
said for consumer control of buffer sizes (to say nothing of providing
