In that case I think it should be included, but I have one change request...
Change the order of arguments to: -spec get(key(K), dictionary(K, V), value(V)) -> value(V). This is in alignment with proplists:get_value/3. Cheers, Torben On Fri, Jun 17, 2011 at 18:42, Martin Logan <[email protected]> wrote: > I feel strongly that it is worth it. I constantly have to write such > functions. The GAS application for config management uses exactly > that syntax and it makes nesting functions so much easier. I vote a > strong yes for inclusion. > > On Fri, Jun 17, 2011 at 11:00 AM, Eric Merritt <[email protected]> > wrote: > > As Torben reminded me, this is an api divergence from dictionaries and > > its mostly just a syntactic short cut. We discussed this and thought > > we would put it to the list to get feed back before we made it part of > > the api. > > > > So in essence, this: > > > > ec_dictionary:get(some_key, a_default_value_if_key_does_not_exist, Dict). > > > > is just shorthand for > > > > try > > ec_dictionary:get(some_key, Dict) > > catch > > throw:not_found -> > > a_default_value_if_key_does_not_exist > > end > > > > So that being the case, is it worth putting into the signature? or > > would something along the dict's module find function be better that > > would look more like this > > > > case ec_dictionary:find(some_key, Dict) of > > error -> > > a_default_value_if_key_does_not_exist > > {ok, Value} -> > > Value > > end > > > > I am not a big fan of find in general, I think the normal get that > > throws an exception gives you the same value or an easy way to > > replicate that value. > > > > In any case, its in your hands now, what do you think? > > > > > > > > On Thu, Jun 16, 2011 at 12:35 PM, Jordan Wilberding > > <[email protected]> wrote: > >> Good catch. > >> > >> On Wed, Jun 15, 2011 at 9:40 PM, Eric Merritt <[email protected]> > >> wrote: > >>> > >>> Guys, > >>> > >>> I just realized that we need a get with a default value for our > >>> signatures. I will put one out for review. > >>> > >>> Eric > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "erlware-dev" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>> http://groups.google.com/group/erlware-dev?hl=en. > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "erlware-dev" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/erlware-dev?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > > > > > > > -- > Martin Logan > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/martinjlogan > http://erlware.org > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > -- http://www.linkedin.com/in/torbenhoffmann -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
