Re: Multiple args: opts map vs inline arguments
What I tend to do when I run into this situation is to split my function in
two and provide:
1. an API function that accepts the key/value pairs as named arguments -
per the library coding guidelines
2. an implementation function that accepts a map of args as its last
argument (and destructures it)
then the API function delegates to the implementation function:
(defn foo* "Do something" [a b {:keys [c d] :or {c 1 d "two"}}] ...)
(defn foo "Do something" {:arglists '([a b :c 1 :d "two"])} [a b & args]
(foo* a b args))
Internal functions call whichever version is easiest to use. The arglists
metadata on foo assists users of the library:
user=> (doc foo)
-
user/foo
([a b :c 1 :d "two"])
Do something
Sean
On Tue, Jun 18, 2013 at 3:52 AM, 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 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 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.
>>
>>
>>
>
> --
> --
> 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.
>
>
>
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
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.
Re: Multiple args: opts map vs inline arguments
+10
If the library provided (this :arg style) just to be a convenience for me,
then that purpose completely backfired the moment I had to type (apply
your-fn (apply concat my-args)).
That unnecessary dance was the inspiration for me buying applyconcat.com
(empty; site ideas welcome).
-Steven
On Tuesday, June 18, 2013 8:27:13 AM UTC-5, Colin Jones wrote:
>
> +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 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
>>> 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
>>> 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.
>>> 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.
Re: Multiple args: opts map vs inline arguments
I agree, this approach fits with our code base. Apply induces a significant hit and should be avoided when performance is critical. I tend to let the computer do its job and free my brain estate for more useful things until performance becomes critical. A kind of laziness :)) Luc P. > My rule of thumb for this is if that's something that will be "static" (as > in, set once in the source and never changes) kw options are fine, if it is > likely to be manipulated, is the result of some previous computation, then > a map fits better. > > apply also has a performance cost that's not always welcome. > > On Tuesday, June 18, 2013 3:38:55 PM UTC+2, Luc wrote: > > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > Sub-selecting options with select-key makes things easier to read when > > pruning > > options used by internal fns. > > > > Marginally slower but less brain estate is required to remember valid > > options. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide > > it. > > > > Luc P. > > > > > > > > -- > > Softaddicts> sent by ibisMail from > > my ipad! > > > > -- > -- > 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. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- 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.
Re: Multiple args: opts map vs inline arguments
I think it's more a matter of taste at this point and what choices were made earlier. I chose the explicit destructuring route on optional args in the fn definition a while ago. Nothing prevents us from dealing with anonymous option maps when appropriate, merging, sub-selecting keys, ... (:or ) But it does not happen very often in our world. As far as calling libs underneath, we just try to avoid option name clashing and sub select whatever options need to be passed to these libs often by name not as a generic map. We do not attempt to hide low level options in our APIs. Of course if a external lib API changes it has some effect on the calling code but it's been a non issue so far. A macro to hide the apply call in this specific case does not appear to me as a lot of work if it simplifies the calling conventions in some edge cases. It would be different if we had this everywhere. My opinion is obviously biased by the choices we made earlier and the way our code base evolved but so far we did not feel any pain choosing this route. Luc P. > On 18 June 2013 14:38, Softaddicts wrote: > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > You can use destructuring on rolled up option maps as well. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > I find myself constructing option maps quite often, but then I use a few > libraries heavy on options, like clj-http, which benefit from merging > option maps. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > > > > It seems a fair bit of work to avoid a pair of brackets. > > If you need a macro or function to work around an issue created by some > optional syntax sugar, I'd question whether that syntax sugar is worth it. > > - James > > -- > -- > 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. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- 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.
Re: Multiple args: opts map vs inline arguments
My rule of thumb for this is if that's something that will be "static" (as in, set once in the source and never changes) kw options are fine, if it is likely to be manipulated, is the result of some previous computation, then a map fits better. apply also has a performance cost that's not always welcome. On Tuesday, June 18, 2013 3:38:55 PM UTC+2, Luc wrote: > > I use destructuring most of the time, the main benefits I see are runtime > validation > of typo errors in the option names, better doc strings and the ability to > provide defaults > where nil does not make any sense. > > Of course you may need to use apply to pass options in turn to another fn > but I found out that this happens most of the time internally, not in the > public API. > > Sub-selecting options with select-key makes things easier to read when > pruning > options used by internal fns. > > Marginally slower but less brain estate is required to remember valid > options. > > If the apply stuff gets repeatedly in the way, then use a macro to hide > it. > > Luc P. > > > > -- > Softaddicts> sent by ibisMail from > my ipad! > -- -- 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.
Re: Multiple args: opts map vs inline arguments
I was not aware of this, we used a macro I think in a few places, mainly to avoid adding an extra call. Luc P. > The keyword arguments vs. (apply (apply)) issue has come up before: > https://groups.google.com/d/topic/clojure-dev/9ctJC-LXNps/discussion > My take is: Use keyword arguments wherever appropriate and keep apply-kw > handy: http://dev.clojure.org/jira/browse/CINCU-3 > > > 2013/6/18 Softaddicts > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > Sub-selecting options with select-key makes things easier to read when > > pruning > > options used by internal fns. > > > > Marginally slower but less brain estate is required to remember valid > > options. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > > > > Luc P. > > > > > > > > -- > > Softaddicts sent by ibisMail from my ipad! > > > > -- > > -- > > 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. > > > > > > > > -- > -- > 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. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- 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.
Re: Multiple args: opts map vs inline arguments
On 18 June 2013 14:38, Softaddicts wrote: > I use destructuring most of the time, the main benefits I see are runtime > validation > of typo errors in the option names, better doc strings and the ability to > provide defaults > where nil does not make any sense. > You can use destructuring on rolled up option maps as well. > Of course you may need to use apply to pass options in turn to another fn > but I found out that this happens most of the time internally, not in the > public API. > I find myself constructing option maps quite often, but then I use a few libraries heavy on options, like clj-http, which benefit from merging option maps. > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > It seems a fair bit of work to avoid a pair of brackets. If you need a macro or function to work around an issue created by some optional syntax sugar, I'd question whether that syntax sugar is worth it. - James -- -- 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.
Re: Multiple args: opts map vs inline arguments
The keyword arguments vs. (apply (apply)) issue has come up before: https://groups.google.com/d/topic/clojure-dev/9ctJC-LXNps/discussion My take is: Use keyword arguments wherever appropriate and keep apply-kw handy: http://dev.clojure.org/jira/browse/CINCU-3 2013/6/18 Softaddicts > I use destructuring most of the time, the main benefits I see are runtime > validation > of typo errors in the option names, better doc strings and the ability to > provide defaults > where nil does not make any sense. > > Of course you may need to use apply to pass options in turn to another fn > but I found out that this happens most of the time internally, not in the > public API. > > Sub-selecting options with select-key makes things easier to read when > pruning > options used by internal fns. > > Marginally slower but less brain estate is required to remember valid > options. > > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > > Luc P. > > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > -- > 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. > > > -- -- 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.
Re: Multiple args: opts map vs inline arguments
I use destructuring most of the time, the main benefits I see are runtime validation of typo errors in the option names, better doc strings and the ability to provide defaults where nil does not make any sense. Of course you may need to use apply to pass options in turn to another fn but I found out that this happens most of the time internally, not in the public API. Sub-selecting options with select-key makes things easier to read when pruning options used by internal fns. Marginally slower but less brain estate is required to remember valid options. If the apply stuff gets repeatedly in the way, then use a macro to hide it. Luc P. -- Softaddicts sent by ibisMail from my ipad! -- -- 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.
Re: Multiple args: opts map vs inline arguments
+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 >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
>> 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
>> 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 .
>> 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.
Re: Multiple args: opts map vs inline arguments
The code for dmirylenka's release-sharks form tdsl.search> (defn release-sharks [n & {:keys [laser-beams]}] (if (boolean laser-beams) (repeat (int n) :shark)))#'tdsl.search/release-sharkstdsl.search> (release-sharks 2 :laser-beams 1)(:shark :shark) 18.06.2013, 14:32, "dmirylenka" :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+StandardsOn 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 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.
--
--
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.
Re: Multiple args: opts map vs inline arguments
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 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 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.
>
>
>
--
--
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.
Re: Multiple args: opts map vs inline arguments
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 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.
Multiple args: opts map vs inline arguments
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 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.
