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 potential fakes for test purposes). In that scenario you'd essentially be *mutating* the input when you set up the go-loop that feeds (or takes input from) the channel, yes? So in effect they become out-params. Doable but odd.
Brian On Fri, Oct 3, 2014 at 7:00 PM, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > 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 about > buffering. > > -S > > > > > Friday, October 3, 2014 12:06:05 PM UTC-4, Brian Guthrie wrote: >> >> 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 to write it >> out. >> >> What I'm asking is whether it's preferable to set up a construction >> function and return a record (or map) with :in and :out keys, with the >> expectation that consumers can manipulate those channels directly, or >> expose functions like read-line and write-line that returns a channel which >> yields and closes once on completion. >> >> Essentially, it's the difference between writing: >> >> (let [sock (socket-client "localhost" 1024) >> line (async/<! (:in sock))] >> ...) >> >> or writing: >> >> (let [sock (socket-client "localhost" 1024) >> line (async/<! (read-line sock))] >> ...) >> >> The disadvantage to the latter approach is that it breaks the channel >> contract: channels should return nil on closure. With single-yield >> channels, detecting nil closure is tiresome: you intentionally return an >> empty channel. And though the function name is nice and clear, it seems >> like a lot of effort to put up a nice facade, especially if folks are >> already comfortable managing channels directly. >> >> Any thoughts? >> >> Thanks, >> >> Brian >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
