<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 4:23 PM, Siraaj Khandkar <span dir="ltr"><<a href="mailto:siraaj@khandkar.net" target="_blank">siraaj@khandkar.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When keys are defined statically (i.e. they do not change at run time), such as process state, a tuple (such as an Erlang record) is the semantically-correct choice.</blockquote></div><br></div><div class="gmail_extra">Another important point is that all keys needs to have valid data always. Otherwise you may have a key mapping to undefined, and that is often an example of illegal state you can represent.<br><br></div><div class="gmail_extra">In general I try to limit the amount of knowledge of records outside its using module and at most put them locally in an application-scoped .hrl (in the src dir). Records bind tightly in the sense that any module using a record needs to know about its structure.<br><br></div><div class="gmail_extra">For ad-hoc returns, I sometimes use a map rather than a tuple. enacl has an example of you generate a key:<br><br></div><div class="gmail_extra">#{ public := PK, secret := SK } = enacl:box_keypair(),<br><br></div><div class="gmail_extra">which makes it harder to accidentally swap the PK and SK of a keypair since you are forced to say what goes first and what goes second. In general, I tend to do this for things where you have multiple values of the same type in statically typed languages, but in dynamically typed languages I sometimes do this even more often to avoid swaps.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>