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 <lprefonta...@softaddicts.ca> 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<lprefonta...@softaddicts.ca> 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.
