On Wed 28 Aug 2013 at 12:50:19PM +0900, Alan Busby wrote: > On Wed, Aug 28, 2013 at 12:18 PM, guns <s...@sungpae.com> wrote: > > > Oh, I was confused; I was thinking about sentinel values in user > > code. Yes, I imagine a single private (Object.) would work just > > fine, with very little overhead. > > Third, I'd recommend reviewing, > http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html to > understand why core.async is not just a better queue.
In my mind, core.async is a nice marriage of BlockingQueues, async processing, and a supercharged POSIX select(2) that works on queue objects. Nothing about these ideas necessarily requires that null be reserved by the channel implementation. > Fourth, if you dislike how core.async works, just wrap it in > your own library so it works the way you'd like. It looks like > "core.async-with-nil" is available on Clojars. ;) > > With nil, without nil, it's just bike shedding. Clojure gives you the > freedom to do it the way you want. Rich Hickey, from: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html > While the library is still in an early state, we are ready for people > to start trying it out and giving us feedback. I think mikera is trying to be constructive. For my own part, I am quite ambivalent since I am already used to avoiding pushing nulls onto Queues. I am quite happy to accept that this is an implementation detail and move on, but I can also see why it might be worth it to support nil channel values to avoid confusing users that are not familiar with this quirk of java.util.Queue. guns
pgpQWVvS0WkaO.pgp
Description: PGP signature
