4 ms·
(when (seq s) ...) reads to me as "do this as long as I can treat s sequentially". The following operations on s require it to be seqable, so it's like a runtim
by mullr 12y ago
(when (seq s) ...) reads to me as "do this as long as I can treat s sequentially". The following operations on s require it to be seqable, so it's like a runtime type check. not-empty is less direct, and feels like it's assuming that s is seqable.
Of course, not-empty is implemented with (when (seq)), so there's no REAL difference. At the end of the day, (when (seq)) is what people use.
- mkremins 12y agoThis interpretation is error-prone. (seq 1), for instance, throws an IllegalArgumentException at runtime. Meanwhile, (seq nil) returns a falsey value even though in many cases it's possible to transparently pass nil in place of a collection of any kind. Essentially, seq already assumes that its argument is seqable. Don't use it to test an argument of unknown type for seqability; prefer something like the seqable? function from core.incubator [1], or a different core function like coll? or sequential? where the semantics of one of these will do. [1] https://github.com/clojure/core.incubator/blob/master/src/main/clojure/clojure/core/incubator.clj#L83 https://github.com/clojure/core.incubator/blob/master/src/ma...