[erlang-questions] maps or records?

[Jesper Louis Andersen]

On Mon, Feb 29, 2016 at 4:28 PM, Siraaj Khandkar <siraaj@REDACTED>
wrote:

> In other words, I'm saying it is very possible to have this cake (of
> public structure) and eat it too (in private, without anyone accessing the
> rapidly-changing, secret cream) :)


You are so close to the idea of view types, and Torben hinted me I should
say something about them :)

One advantage of a function is that it doesn't have to give you the field
outright, but can provide ways to dynamically cast that structure into
another structure you export. Two really good examples is that you can
return some kind of tuple depending on the contents of the data and thus
you can build a case match on the data. This ad-hoc
for-the-purpose-construction of a datatype can often yield far more precise
code since it splits analysis of what is *in* the datastructure from
computation which says what to *do* about that data. Say we have a #uri{}
record. The path component has many possible representations: a binary(), a
list of binaries, an iterator, and so on. Different view-functions would
give you different ways to handle that binary.

Another nice thing is that functions can give you are
zipper/derivative/delimiting-continuation over the data in the structure.
The path-component can then be unfolded one path-entry at a time:

pth(X) ->
    case http_uri:unfold_path(X) of
        none -> ...;
        {some, C, X2} ->
           ... C ... pth(X2)
    end.

or you can imagine a gb_trees/gb_sets like iterator over the data structure.

A plain map() cannot give any of these ideas, and its transparency also
tightly couples your code to the map() structure. So one has to carefully
weigh what kind of interface you want in the long run. I much prefer views
of the data structures if possible since it allows for more freedom in the
long run, but it requires you to be able to figure out what kind of
functions you would need a priori on the data. On the other hand, it
provides for much better hiding of what is going on inside the module,
which allows you more flexibility regarding backwards compatibility.

In other words: exporting records across application boundaries tend to
lock them down, so be pretty sure they are set in stone. Also think hard if
you want every user to implement the analysis code. The view is much like
in a database: do you export the raw records, or do you expose a
transactional API through stored procedures which tell you what you can do
with the data?


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160229/8691ae64/attachment.htm>