
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span style="background-color: rgba(255, 255, 255, 0);">Hi Jesper,</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">> I tend to use an algebraic datatype instead, </span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Can you please explain this. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Many thanks,,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">LRP<br><br>Sent from my iPad</div><div><br>On Oct 1, 2016, at 3:24 PM, Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>-record(state, { name, socket }).</div><div><br></div><div>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</div><div><br></div><div>-type state() :: {unconnected, name()} | {connected, name(), socket()}.</div><div><br></div><div>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</div><div><br></div><div>barney(#{ socket := Sock }) -> ...</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 12:37 PM, Pagayon, Ruel <span dir="ltr"><<a href="mailto:ruel@ruel.me" target="_blank">ruel@ruel.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone,

<div><br></div><div>I'm just wondering (assuming the keys of my maps in my application is not dynamically generated):</div><div><br></div><div>1. What is the most optimal key type for maps?<br></div><div>2. If there is little to no effect in performance (or resources in general), as a convention, which is the best to use?</div><div><br></div><div>Thank you in advance for your responses.</div><div><br></div><div>Cheers,</div><div>Ruel</div></div>

<br>______________________________<wbr>_________________<br>

erlang-questions mailing list<br>

<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>

<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>

<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>

</div>

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>erlang-questions mailing list</span><br><span><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></span><br><span><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></span><br></div></blockquote></body></html>