how do you guys feel about 'pure' functions and annoying signatures?
(defn contains-rc-branch? [^SVNRepository repo ^String path]
(not= nil (get-directories repo (str path "/branches/RC"))))
(defn contains-trunk-folder? [^SVNRepository repo ^String path]
(not= nil (get-directories repo (str path "/trunk"))))
(defn get-projects [^SVNRepository repo ^String path]
(->> (get-all-directories repo path 3)
(filter (partial contains-rc-branch? repo))
(filter (partial contains-trunk-folder? repo))))
Passing in the SVN object means every functions need an extra arg and is getting passed around within the ns everywhere. Are free variables within a ns so bad?the alternative you are proposing is something like (def repo ...)
then leaving it out of all the functions. that is not a good way to write code if you want to test it or reuse it. namespaces are not classes, there is no method to create different "instances" of a namespace with different values for repo
yeah thats pretty much what I thought. I've just been noticing that a lot of my code ends up in anon fns or calls to partial which break the readability and hide the business logic.
especially around filter/reduce/map. which is supposed to be the bread and butter of FP's readability use case
not a big deal i guess, the benefits are worth a little thinking differently
(defn filter-successful-deploy [deploys]
(filter #(= "SUCCESS" (:deploymentState %)) deploys))
(defn get-environment [{env-name :name
id :id}]
(-> (call-until-success (str base "deploy/environment/" id "/results") 10)
:results
filter-successful-deploy
first
(assoc :env-name env-name)))
usually just wrap up the filter with a named fn and suddenly the business intent becomes pretty clear again
although it looks like in that example i should have passed in the base variable instead of relying on it as a constant in my ns
sigh... i feel like OOP has ruined my brain