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.

Reply via email to