In the blog post, tcrayford gives an example of the difficulties in
wrapping a kwargs function:
(defn my-wrapper [& kwargs]
(let [options (assoc (apply hash-map kwargs) :my-default-arg 1)]
(apply (your-api-fn (flatten (into '() options))))))
Sure, that's convoluted (and I couldn't actually get it to work on real
code).
But isn't this a much simpler way:
(defn my-wrapper [& kwargs]
(apply your-api-fn :my-default-arg 1 kwargs))
Am I overlooking something?
On Mon, Mar 23, 2015 at 5:55 AM, tcrayford <[email protected]> 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 [email protected]
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> [email protected]
> 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 [email protected].
> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
