<div dir="ltr"><div dir="ltr">Am Mo., 23. Sept. 2019 um 13:15 Uhr schrieb Brujo Benavides <<a href="mailto:elbrujohalcon@gmail.com">elbrujohalcon@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">There is some <i>historical</i><span style="font-style:normal"> context at play here, Karl.</span><div>Records (which are, in many occasions, the predecessors of maps) are tuples and therefore it’s not uncommon to find code that uses the functions listed by Vance to work with them. For instance…</div><div><br></div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">    </span>find_user(UserName, Users) -></div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">             </span>lists:keyfind(UserName, #user.username, Users).</div><div><br></div><div>If we move from records to maps as our means to implement users, then we need something like…</div><div><br></div><div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">   </span>find_user(UserName, Users) -></div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">             </span>case lists:dropwhile(fun(#{username := UN}) -> UN =/= UserName end, Users) of</div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">                    </span>[] -> false;</div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">                      </span>[User|_] -> User</div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">          </span>end.</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>It would be <i>nice</i> if we don’t need to do that and instead can do…</div><div><br></div><div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">       </span>find_user(UserName, Users) -></div><div><span class="gmail-m_8462269937922398703Apple-tab-span" style="white-space:pre-wrap">             </span>lists:keyfind_for_maps(UserName, username, Users).</div></div></div></blockquote><div><br></div><div>Your example doesn't make sense to me. Why don't you simply use a map with the username as key?</div><div><br></div><div>Maps are a Key-Value stores. If you need secondary indices, you can always maintain additional maps for them. Non-unique secondary keys can be implemented by using a maps as value. Or use an ets where you can match on additional fields.</div><div>Adding a linear search like lists:keyfind to maps make no sense in my opinion.</div><div><br></div><div>Talking about ets, adding a match like API to maps might make sense. If only to make it possible to replace ets with maps without having to change to much code.</div><div><br></div><div>Regards</div><div>Andreas</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div></div></blockquote><div> </div><div>[...]</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><p><span style="font-family:verdana,geneva,sans-serif;font-size:10pt">Andreas Schultz</span></p>
<p><br></p></div></div>