[erlang-questions] lists module functions for maps?

[Andreas Schultz]

Am Mo., 23. Sept. 2019 um 13:15 Uhr schrieb Brujo Benavides <
elbrujohalcon@REDACTED>:

> There is some *historical* context at play here, Karl.
> 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…
>
> find_user(UserName, Users) ->
> lists:keyfind(UserName, #user.username, Users).
>
> If we move from records to maps as our means to implement users, then we
> need something like…
>
> find_user(UserName, Users) ->
> case lists:dropwhile(fun(#{username := UN}) -> UN =/= UserName end, Users)
> of
> [] -> false;
> [User|_] -> User
> end.
>


> It would be *nice* if we don’t need to do that and instead can do…
>
> find_user(UserName, Users) ->
> lists:keyfind_for_maps(UserName, username, Users).
>

Your example doesn't make sense to me. Why don't you simply use a map with
the username as key?

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.
Adding a linear search like lists:keyfind to maps make no sense in
my opinion.

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.

Regards
Andreas

>
[...]

-- 

Andreas Schultz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190923/f4ba8e44/attachment.htm>