On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume <duelin.mark...@gmail.com> wrote: > Though in some cases the performance impact could be significant, my concern > is readability. My understanding of the concept of partial function > application is that it's about supplying some but not all of the arguments. > So when I see `partial` in code, I expect more arguments to be supplied > later, which is confusing when that's not the case. (Obviously context can > make it easy to see that there will be no more arguments, but often that > context is not present.) >
+1. Using partial to convert a unary func into a nullary func when #() is available strikes me as malpractice. Suppose you were to come across something like this in legacy code: >> (do-work (partial say-hello "bob")) For me, the natural inference would be that say-hello must want at least one more arg (otherwise why partial?), so do-work must be feeding some arg to the result of (partial say-hello "bob"), like adding "Don't worry, we're not watching you", in case the NSA owns do-work. Execution efficiency aside, downstream programmer confusion due to implied semantics also has a cost. -Gregg -- -- 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/groups/opt_out.
