This style is only good if you do damn good naming on your "explaining variables". So while more names can really improve readability, bad names do the opposite by adding confusion and misdirection. This pattern enforces naming for every step. Good names are difficult, so I can only recommend to not use this style as a "silver bullet" or default. If you don't have time for the names in the first place, prefer threading macros, which still provide for great readability and can be edited with less typing overhead.
Note that you could have used the same names as right hand comments in the threading macro which IMO is the best of both worlds. Regarding this discussion in general, I find #(my-fn %) to be preferable over (partial my-fn) in most cases. My understanding is that partial was introduced to the language before the terse lambda #/% syntax and is mostly superseded by it. In summary comp and partial are specifically useful if you transform functions algorithmically! If you just need to chain a few things while typing, #(... %) syntax and the arrow macro are most intuitive to write and read. On Monday, October 31, 2016 at 3:50:08 AM UTC+1, Mikera wrote: > > On Thursday, 27 October 2016 22:56:42 UTC+8, JHacks wrote: >> >> I have some confusion about how the function `comp` works, especially as >> compared to the threading macro `->>`. >> >> From the book *Clojure Programming* (pages 70-71 of Chapter 2: Functional >> Programming), the following two functions are described as functionally >> equivalent: >> >> (def camel->keyword >> (comp keyword >> str/join >> (partial interpose \-) >> (partial map str/lower-case) >> #(str/split % #"(?<=[a-z])(?=[A-Z])"))) >> >> (defn camel->keyword* >> [s] >> (->> (str/split s #"(?<=[a-z])(?=[A-Z])") >> (map str/lower-case) >> (interpose \-) >> str/join >> keyword)) >> >> Why does the first function, `camel->keyword`, need to use `partial` with >> the >> `map` and `interpose` functions? The second function, `camel->keyword*`, >> does >> not need to use `partial`. >> > > I actually prefer the following style to both of the above: > > (defn camel->keyword* > [s] > (let [words (str/split s #"(?<=[a-z])(?=[A-Z])") > lc-words (map str/lower-case words) > joined-words (str/join "-" lc-words)] > (keyword joined-words))) > > Reasons: > - Your intermediate values are explicitly named, which helps to make the > code self-describing > - It is (marginally) more performant than the composed function case (I > think exactly matches the threading macro) > - You can use the intermediate values in more than one of the following > steps if needed, which can make refactoring / adding new features easier > - The ordering is (to me) more logical as it describes the stages of the > transformation in the order they are performed. > - It is less "Clever". Clever code is generally bad for maintenance and > future understanding. Both functional composition and the > code-transformation effects of the threading macro represent conceptual > overhead that you don't need to pay (in this case). > > > > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
