<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 5:04 PM Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div dir="ltr"><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><div dir="ltr"><div class="gmail_extra"><br clear="all"><br>-- <br><div>J.</div>
</div></div><br></blockquote><div><br></div><div>Thanks both for the information it's useful :)</div><div><br></div><div>I think I would use maps in state when the state is persisted in a file. Since it's make it easier when you update the file format to also upgrade the state. </div><div><br></div><div>So would you se a maps instead of a record when you need to share the returned result with apps that depends on your library? Instead of making that result opaque and provide functions to access it? Which sound ridiculous sometimes, since at the end what you do is a get on a record key ... Curious what others do in that case?</div><div><br></div><div>-  benoit</div><div> </div></div></div>