On Sun, Jan 9, 2011 at 9:23 AM, Stuart Halloway
<stuart.hallo...@gmail.com> wrote:
> Additional corner cases to consider:
>
> * nil
Tricky one. It's clearly atomic in the usual sense; at the same time
it can stand in for an empty coll in many cases. I'd call it atomic.
> * arrays
Nonatomic. Is there an #(instance? X %) test, with some substitute for
X, to detect them though?
> * poorly-designed Java classes that are clearly collection-like but don't
> implement collection interfaces.
There's no theoretical way to detect all of these automatically, even
with heavy use of reflection and debug-inspectors. There are surely
ways to disguise collections such that the general case of recognizing
them is equivalent to the halting problem.
In practice, you might want to either just treat anything that's not
an array or a java.util collection as atomic, or else provide a hook
for the caller to supply exceptions:
(defn atom?
([x]
(atom? x (constantly false)))
([x exception?]
(not
(or
(instance? java.util.Collection x)
(instance? java.util.Map x)
(.isArray (.getClass x))
(exception? x)))))
(atom? [1 2 3])
=> false
(atom? {:a 1 :b 2})
=> false
(atom? (make-array String 3))
=> false
(atom? (java.util.HashMap.))
=> false
(atom? 3)
=> true
(atom? 3 #(instance? Number %))
=> false
I'd also say that String is a slightly tricky one, having
collection-like behavior (it's a freaking list of characters!) but
being very commonly used as an atomic thing more than as a collection.
Symbols and keywords should definitely be regarded as atomic.
--
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
