On Mon, Jan 2, 2012 at 5:28 PM, Stephen Compall <stephen.comp...@gmail.com> wrote: > On Sun, 2012-01-01 at 23:16 -0500, Cedric Greevey wrote: >> And that will obviously be chock-full of internals changes and >> miscellaneous tweaks and not just the user-visible feature >> changes/additions, aimed more at developers of Clojure itself than at >> developers using Clojure to make other things. > > No, it's not. That stuff is in `git log'.
Anything that's packaged with the source rather than with the binary, and/or is on the repo site and/or the dev.* site rather than on the main web site, is thereby more or less being *stated* to be intended for the software's developers rather than its users. > Most library functions are shorthand for something else, and much of > their value lies in capturing a common idiom. `not-empty' is used > several times in core.clj itself, and only once as a truth test. Not a representative sample; core.clj does a lot of things weirdly due to things not yet being defined at a particular point, etc. > The usual function to use for truth in this situation is `seq', not > `not-empty'. Yes; not-empty does seem rather redundant with that, other than for the narrow and unusual case where you'd otherwise have (if (seq x) x). But it's more likely you'd have (if (seq x) (...more complex expression using x) (...alternative)) or (if-let [x (seq x)] ...). About the only spot I can think of for using it, offhand, is when calling a function and passing an argument that should be a collection or nil, and wanting the collection type unmodified if it isn't nil, so (seq x) won't do. All of the subcases I can think of offhand, in turn, *do* work fine with (seq x), or even with a non-nil empty collection, for example concat. The case above, where you want to nil out substring if it's not empty but not disturb its stringness, is actually about the only one I think likely, and there are probably other ways to solve the problem, probably by accepting an empty string instead of nil or by moving the empty check to where a nil check is currently used. Nil punning is clever, but sometimes it's cleverness purely for its own sake and at the expense of tangling some of the rest of the code. > ^aCollection allSatisfy: [:each|aCondition]: less is better Eh, another (ex-)Smalltalk hacker? -- 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
