Loading of atoms which have been defined in a module's types

I have a simple struct which has a status field which can be :active, :idle, or nil. Definition looks like here:

defmodule Event do
  defstruct status: nil

  @type t :: %__MODULE__{
          status: nil | :active | :idle
        }
end

Then I have an application which parses JSON representation to create instances of these structs. As part of this, I am calling String.to_existing_atom/1. So "active" from the JSON becomes :active. However, I am getting ArgumentError from String.to_existing_atom/1 due to the atom not being loaded yet.

I have tried Jose’s solution on this github thread whereby Code.ensure_loaded?/1 is called to force loading of the module. But in this case, although the module gets loaded, the atoms here are defined in the module’s typing so it doesn’t appear to create them.

Any suggestions on a clean way to solve this?

1 Like

In my opinion the better alternative to String.to_existing_atom/1 is to be explicit about which values you’ll cast. For example, if you’re creating an Event struct from a string-keyed map (like parsed JSON), it could look something like this:

def new(map) do
  %__MODULE__{
    ... # other fields
    status: cast_status(map["status"])
  }
end

defp cast_status("active"), do: :active
defp cast_status("idle"), do: :idle
defp cast_status(nil), do: nil

This particular example would raise if you got an unacceptable value back from the JSON. If you need to validate the input, something like Ecto changesets would do the trick too. Or if it fit your needs you could just make everything else nil.

6 Likes

Types and Specs are not available at runtime, and therefore have no effects like creating atoms.

You need to actually use those atoms in your code.

1 Like

The sole purpose of String.to_existing_atom/1 would be to raise if the atom is not existing. If you are sure that the source of string in the question is trustful, there is not much sense in using it in general, if the atom already exists, it would be used, atoms are never re-created.

So, AFAICT, this is an XY problem and the simplest although cleanest solution would be to resort to String.to_atom/1 unless you expect values to come from the outside; in that case, it’d be better to handle wrong values in a bit more sophisticated manner.

1 Like

Thank you everyone for the suggestions! I will be more explicit on the parsing side about how to cast the values, rather than using String.to_existing_atom/1. Thanks again.