On Tue 27 Aug 2013 at 07:42:53PM -0700, Mikera wrote: > 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 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 :-)
I agree with you that this is an inconvenience. The bit about avoiding
null even in collections that support null elements because poll uses
null as a sentinel value is a classic leaky abstraction.
That said, I haven't found designing around it to be a terrible
nuisance. I often use queues as messaging channels, so it is natural to
simply send maps or tuples instead of atomic values.
> 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?
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.
guns
pgp0C89I2s0Ka.pgp
Description: PGP signature
