[erlang-questions] Best Practice in Map keys: Atoms or Binaries (or Strings)?

[Jesper Louis Andersen]

Hi,

You have to define optimal. Do you want efficient lookup or do you want to
save space? For static keys, using atoms has the advantage of being fast to
compare and rather small (1 machine word). For small maps, lookup speeds
are so quick I don't think it really matters too much if a record is
marginally faster. I'd go for readability over efficiency in almost all
situations.

As for the record vs maps discussion: I tend to use an algebraic datatype
instead, so I can avoid representing state which is not valid. In some
circumstances, a map is fit for the representation. One weakness of a
record is that if we define

-record(state, { name, socket }).

then we need to have #state { socket = undefined } at some point if we
don't have a valid socket. With a map, we can simply initialize to the
state #{ name => Name } and then when the socket is opened later, we can do
State#{ socket => Sock } in the code and extend the state with a socket
key. In a language such as OCaml, we could represent it as the type

-type state() :: {unconnected, name()} | {connected, name(), socket()}.

And I've done this in Erlang as well. It depends on the complexity of the
representation. As for the goal: the goal is to build a state which is very
hard to accidentally pattern match wrongly on in the code base. If your
state has no socket, a match such as

barney(#{ socket := Sock }) -> ...

cannot match, even by accident. In turn, it forces the code to fail on the
match itself, not later on when you try to do something with an undefined
socket.


On Sat, Oct 1, 2016 at 12:37 PM, Pagayon, Ruel <ruel@REDACTED> wrote:

> Hi everyone,
>
> I'm just wondering (assuming the keys of my maps in my application is not
> dynamically generated):
>
> 1. What is the most optimal key type for maps?
> 2. If there is little to no effect in performance (or resources in
> general), as a convention, which is the best to use?
>
> Thank you in advance for your responses.
>
> Cheers,
> Ruel
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161001/251e578a/attachment.htm>