fcheung
Choosing between maps, structs, records etc
Hi,
As I mentioned in an earlier topic, I’m playing with building an elixir client for the AWS apis from api definitions they provide. These apis have lots of different return types, also described by these api definitions. I’m wondering what data types the elixir implementations should return.
They could just return maps (and the values inside by further maps/lists/strings/numbers etc.) but I’m worried about this being error prone from the point of view of the user. It’s very easy to typo a map key (I swap US and UK spellings all the time for example).
I could define structs for all the various return types, but there are a lot of those (since there are lots of apis, and some of the return / input types are themselves made up of many types) and this seems to make compilation slow. To give an order of magnitude, when I tried this with just the EC2 api, I ended up with 536 structs and compiling a file that just defines those structs takes 18 seconds on my machine. (As an aside are there other costs / overheads associated with having hundreds of modules that just define a struct? Across all the aws apis there would be many thousands of these structs).
I read through José’s post on some the rational for structs and for this use case a lot of it isn’t necessary - I do just want some compile time checks & easy discoverability of what these apis return.
I’ve come across records via the post I linked earlier, but they don’t seem to get a lot of use (the Programming Elixir book doesn’t even mention them). Using either structs or records feels a bit like I might be trying too hard to recreate what I might do in ruby. Posts such as https://engineering.appcues.com/2016/02/02/too-many-dicts.html do seem to encourage the use of structs.
Lastly I’ve seen type specifications. “Programming Elixir” says “type specifications are not currently in wide use in the Elixir world” and José’s post does say that typespec support for maps is lacking. Both of these are from 18+ months ago though - the release notes for erlang 19 do say that dialyzer support for maps is “very much extended” & http://elixir-lang.org/docs/stable/elixir/typespecs.html certainly seems to list some of the features I’d want - required keys, optional keys etc.
The process of writing this nudged me slightly in the direction of maps + type specs, but I would love to hear more informed opinions!
Marked As Solved
josevalim
Yes.
Only when defining hundreds.
Also Liked
josevalim
Think of records as glorified tuples. When you need to handle multiple different tuples, which are private to a module, records work great. Maps would also work in the example above, but they wouldn’t give the compile time guarantee of records. Structs would be too wasteful though for those cases. Those data structures are never really “exported”, so using multiple modules for representing them is quite unnecessary.
josevalim
The sheer amount of data types seems to make the structs road unfeasible. I would go with maps because they are still typo safe: map.foo will raise if the field foo does not exist, as well as pattern matching on %{foo: foo}. It does suffer a bit on discoverability when compared to structs.
fcheung
That makes sense. I can populate the maps with nils for fields that are optional in api responses.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









