Your article makes things a little more complicated than they need to be -- there is a special destructuring syntax in Clojure for pouring keyword args directly into a map (just do the map destructuring after the &). Also, I don't think you need to flatten the map of keyword args before calling "apply". It's been a while since I've tested this, but I believe that if a map is passed as the last argument to apply, Clojure "does the right thing" and passes the map in as keyword args.
Despite that, I agree with you that keyword arg functions don't compose as well. If I'm remembering correctly, I think the biggest problem I ran into is that the :or destructuring technique for supplying default values only uses the default values if the specified keys are *missing* from the keyword args (as opposed to using the default values if the keyword args are set to nil). This became a problem when I'd destructure in one function (which would bind missing keys to nil) and then pass along the keywords to the next function. The missing keywords weren't treated as missing, and so the default values weren't supplied. It's been a while since I've needed to do this, so I apologize in advance if I'm inadvertently passing along some misinformation here. On Mon, Mar 23, 2015 at 2:55 AM, tcrayford <tcrayf...@gmail.com> wrote: > Hi there, > > I feel pretty strongly about this - I *much* prefer using APIs with > explicit options maps. The community is pretty divided though. I wrote up > the tradeoffs (which are well discussed here as well), as well as a list of > libraries using each style: > http://yellerapp.com/posts/2015-03-22-the-trouble-with-kwargs.html > > To me, typing two extra characters ain't a big deal, but unrolling/rolling > up maps and not being able to manipulate options easily is a bunch of pain, > so I always choose explicit maps wherever possible. > > On Tuesday, 17 March 2015 06:42:37 UTC+9, Leon Grapenthin wrote: >> >> Kwargs has clearly been designed for one purpose: A caller should have to >> type less. >> >> A simple rule to follow is to use kw args if the exposed thing is a >> function not expected to be used in functional composition or a certain >> DSLish kind of macro. >> >> If your exposed function will be used in functional composition more >> often than called in typed out code, with kwargs you are using the feature >> to its opposite purpose: People have to type even more. >> >> For an example, if your thing is called "load-config-file!" and is used >> in one or two places of code, use kwargs by all means. If your thing is >> called path-for and resolves an URL for a map of parameters, kwargs is a >> very unfortunate choice. >> >> >> On Saturday, April 26, 2014 at 12:41:22 AM UTC+2, Colin Fleming wrote: >>> >>> Hi all, >>> >>> I'm working on an API at the moment, and I'm balancing whether to use >>> inline keyword args which I would destructure in the functions, or whether >>> to just pass an explicit params map as the last parameter. Comparison of >>> the two options in case I'm not explaining myself well: >>> >>> Kwargs: >>> (class/create-class :instance list >>> :description "My description" >>> :implements (keys class-methods) >>> :methods (calculate-my-methods)) >>> >>> Map: >>> (class/create-class {:instance list >>> :description "My description" >>> :implements (keys class-methods) >>> :methods (calculate-my-methods)}) >>> >>> A lot of APIs I've seen have favoured kwargs, and it undeniably makes >>> for some pretty code - Seesaw is the best example I've seen here, the API >>> is a thing of beauty. However it seems to me to have some issues: >>> >>> 1. If I want to delegate to another call from within an API function >>> and use the same arguments, it's really awkward: (apply delegate >>> (mapcat identity args)) or some similarly awful black juxt magic. Or >>> of course writing out all the parameters again, but that's even worse. >>> 2. It's more difficult to make parameters optional based on some >>> runtime criteria since the params are baked into the function call. I >>> guess >>> this is usually dealt with by making the calls handle nil for a >>> particular >>> parameter. >>> >>> Both of these are much easier when passing an explicit map. Any >>> preferences here, from either writing or using APIs like this? >>> >>> Cheers, >>> >>> Colin >>> >> -- > 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. > -- 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.
