If there are enough optional args that they need to be named then I choose a map, every time. That said, I do must multi-arity fns quite a bunch as well (with the options map going on the end if applicable).
I also depend quite heavily on prismatic's schema, and to a lesser extent core.typed and I am not sure how charges fit in with either of those, although I haven't tried. +1 for maps. On 23 March 2015 at 09:55, 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: >>> >>> 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. >>> 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.
