[erlang-questions] maps or records?

[Benoit Chesneau]

On Fri, Feb 26, 2016 at 5:04 PM Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

>
> On Fri, Feb 26, 2016 at 4:23 PM, Siraaj Khandkar <siraaj@REDACTED>
> wrote:
>
>> 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.
>
>
> 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.
>
> 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.
>
> For ad-hoc returns, I sometimes use a map rather than a tuple. enacl has
> an example of you generate a key:
>
> #{ public := PK, secret := SK } = enacl:box_keypair(),
>
> 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.
>
>
> --
> J.
>
>
Thanks both for the information it's useful :)

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.

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?

-  benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160226/9f32dca0/attachment.htm>