How to convert a typed definition to a typedstruct?

Questions / Help
, ,
1

Background

I am moving towards defined data structures in my application, and I find that TypedStruct is quite useful.

Questions

However, I have recently found a little hickup. I don’t know how to convert this definition into a typedstruct:

  @type order_info :: %{
    (visible :: String.t()) => boolean,
    (order_type :: String.t()) => String.t(),
    (platform :: String.t()) => String.t(),
    (platinum :: String.t()) => non_neg_integer,
    (user :: String.t()) => %{
      (ingame_name :: String.t()) => String.t(),
      (status :: String.t()) => String.t()
    }
  }

My main issue here is the user map. Aside from the fact I don’t know how to define a typedstruct inside a trypedstruct, how do you guys do this?

  1. Do you simply define a map inside the order_info typedstruct and ignore the mandatory parameters for the user map?
  2. Do you create another typedstruct (called user) that goes inside the typedsctruct called order_info?
  3. What is the standard option in Elixir ?
2

Looks like TypedStruct supports all typespec in Elixir. If that’s true then depending on your needs you can use a map notation or reference to other type - just like you do with String.t(). I do not see a problem if referenced module would also use TypedStruct.

1 Like
3

I’m also a great fan of TypedStruct (and its cousin TypedEctoSchema).
I would definitely go for defining a User struct.
The reasoning for doing that would be the same as for creating the OrderInfo struct in the first place: Ensuring that mandatory fields are present, and make it clearer what is passed around.
If User is only used in the context of OrderInfo, I would name it accordingly, i.e. OrderInfo.User.

I have to admit that I try to use (typed)structs as often as possible – maybe even too often. But I like the fact that I can be explicit about expectations. I also try to ensure that I pattern match against the expected struct in the function heads that expect structs as input.

2 Likes
4

Quite interesting !
Do you also add a new function to build the structs? Or do you simply build them manually?

I understand you are advocating for nested module in this use case. Could you please be so kind as to share how your final solution for this would look like?

5

I’m actually quite undecided on that part. The OOP-developer in me really wants a new-function, as it allows me to have the required fields as required parameters, and then an optional keyword-list or map as the last parameter to fill in optional fields. (It also allows fields to be calculated).

However, lately I am questioning that approach for several reasons: First, the Elixir compiler is quite good at complaining about missing required fields. Second, that last optional parameter taking a map or keyword-list is really not nice to deal. Third, when you have more than three required fields, the approach results in a large number of parameters to the new-function.
Now I am trying to embrace structs as open (non-hiding) data structures. No constructors, and no calculated fields.

“Nested” in the sense of namespace, not in code, though. I really try to keep strictly to one-module per file. I would have the following directory structure:

lib/
  order_info/
    user.ex
  order_info.ex

order_info.ex would then contain something like this:

defmodule OrderInfo do
  use TypedStruct

  typedstruct do
  ..
  end

and, order_info/user.ex:

defmodule OrderInfo.User do
  use TypedStruct

  typedstruct do
  ..
  end
6

Agreed, just having a few layers of keyword options passed around, with defaults and some having to override others etc., it becomes a huge rabbit hole that’s an extremely easy vector to introduce bugs.

That being said, I’ve been trying to use NimbleOptions in my own hobby work lately and so far it’s serving me pretty well. Bonus points for also serving as kind of a typed schema as well, that was a nice and very welcome surprise.

Yeah, that’s the biggest problem here, and that’s why I started using NimbleOptions and having only a single parameter – the keyword list – which in effect imitates the named function arguments that other languages enjoy (like OCaml). So far I like the result but it’s too early to say because my own hobby OSS work is going at a snail’s pace. Time will tell but tentatively, that library makes things possible and much less annoying.

7

NimbleOptions looks interesting. I will check that out. Thank you for the pointer.