+1 James.
I can't count the number of times I've found myself unrolling an options
map with a dance like this apply / apply concat.
And don't forget that the function itself then has to roll this options map
back up to operate on it, which syntactically isn't all that bad, but it
usually seems like a lot of unnecessary work, when the payoff is just to
omit a set of curly braces. Maybe it's not even that big of a performance
issue, but I find there's a mental overhead for me.
Other considerations:
- If you need two options maps for some reason (maybe one to delegate
elsewhere), one will have to be non-varargs.
- Should the consumer of the function be required to pass *some* options?
If so, using varargs options means even more work to verify that.
I won't go so far as to say that I never use the varargs/unrolled version.
I'm sure they're great if you always call a function with literal values,
like the `(release-sharks 2 :laser-beams true)` example. But I do find them
painful more often than not.
- Colin
On Tuesday, June 18, 2013 5:52:51 AM UTC-5, James Reeves wrote:
>
> I somewhat disagree with the coding standards in certain cases. If you
> have a large number of options, you may find yourself creating the option
> map programmatically. In which case:
>
> (release-sharks 2 options)
>
> Is preferable to:
>
> (apply release-sharks 2 (apply concat options))
>
> - James
>
> On 18 June 2013 06:32, dmirylenka <daniilm...@gmail.com <javascript:>>wrote:
>
>> According, to the library coding standards, the first is better:
>>
>> (release-sharks 2 :laser-beams true) ; good
>> (release-sharks 2 {:laser-beams true}) ; bad
>>
>> http://dev.clojure.org/display/design/Library+Coding+Standards
>>
>>
>> On Tuesday, June 18, 2013 5:26:15 PM UTC+12, Omer Iqbal wrote:
>>>
>>> Hey folks,
>>>
>>> What'c considered more idiomatic when having multiple, optional
>>> arguments?
>>>
>>> (defn foo1 [a b & args]
>>> (let [opts (apply hash-map args]
>>> ...))
>>>
>>> or
>>>
>>> (defn foo2 [a b opts]
>>> ...)
>>>
>>>
>>> Cheers,
>>> Omer
>>>
>>>
>>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> 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+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
--
--
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/groups/opt_out.
