Ha! I just noticed that this thread was started a year ago, and I posted a similar comment back then. Well, at least I'm consistent :)
On Mon, Mar 23, 2015 at 3:13 AM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > 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.
