Well, that's certainly a good explanation of why core.async works the way it does now - it's a natural and sensible starting point to build on Java Queues.
I don't think that this necessarily implies that we have to follow this model in the future Clojure API though. The Java designers didn't always get everything right :-) There's no reason I can see why core.async can't internally substitute its own nil-representing value into the underlying Java infrastructure. And this would free users of core.async from the burden of doing this translation every time that the transmission of nil values is desired. As for "configurable sentinel value": I'm less sure that there's a need for this. In fact, I think it's more useful to guarantee a standard sentinel value so that different channel-handling code can interoperate. I just think that this sentinel shouldn't be nil (or any other regular Clojure value). A simple singleton object that is privately owned by core.async should suffice? On Wednesday, 28 August 2013 09:54:51 UTC+8, guns wrote: > > On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote: > > > Of course, if anyone has an actual technical argument why it is > > necessary/better to use nil as a sentinel value, I would be delighted to > > learn of it and would consider myself enlightened. > > Forgive me if someone already mentioned this, but isn't this simply a > consequence of building on the existing Java Queue implementations? > > Quoting http://docs.oracle.com/javase/7/docs/api/java/util/Queue.html: > > Queue implementations generally do not allow insertion of null > elements, although some implementations, such as LinkedList, do not > prohibit insertion of null. Even in the implementations that permit > it, null should not be inserted into a Queue, as null is also used > as a special return value by the poll method to indicate that the > queue contains no elements. > > I think most would agree with you that a configurable sentinel value > is best (I like using ::namespaced-keywords myself), but the existing > machinery has already decided on null, so that's what we have. > > guns > -- -- 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/groups/opt_out.
