Shared module constants

The usual approach would be to use atoms inside the system, e.g. :source_lvl1_api and convert to/from integer encoding on the system boundary, if needed. This makes it easy for debugging and introspection since at runtime you have readable atoms, instead of opaque integer values flying around. You can generate the conversion functions easily with a sprinkle of macros:

values = [source_lvl1_api: 301023, ...]
for {key, value} <- values do
  def encode(unquote(key)),   do: unquote(value)
  def decode(unquote(value)), do: unquote(key)
end

You can also store it into a map that is returned from a function like this:

def Consts, do: %{
  AUDIT_ENTITY_REV_TYPE_DELETE: 301001,
  AUDIT_ENTITY_REV_TYPE_INSERT: 301002,
  ...
}

Being a constant object in the code with no variables it gets constructed fast, however usual things in Erlang/Elixir get optimized into the bytecode so no construction actually takes place and it gets shared easily, I’m not sure if maps do that however.

Overall @michalmuskala method is usually best, no construction time at all, however the lookup time can be linear in a match set like that so a map might be faster in lookup speed.

Thanks both

So it looks like @OvermindDL1 idea of using a map would be the easiest way to get them across, but I’m intrigued by what you said @michalmuskala.

I’m not sure I fully grasp what you are suggesting, are you saying that the conversion would happen at the point that things are inserted and retrieved from the database? I’m struggling to figure out where those macros would live and how they would be used in other modules.

+1 to map solution since keyword list can have duplicate keys and with many constants it might become a problem down the way

I have a macro for reusing constants across multiple modules. The benefit being that they work in matches and in guards.

defmodule Constants do
  @moduledoc """
  An alternative to use @constant_name value approach to defined reusable 
  constants in elixir. 

  This module offers an approach to define these in a
  module that can be shared with other modules. They are implemented with 
  macros so they can be used in guards and matches

  ## Examples: 

  Create a module to define your shared constants

      defmodule MyConstants do
        use Constants

        define something,   10
        define another,     20
      end

  Use the constants

      defmodule MyModule do
        require MyConstants
        alias MyConstants, as: Const

        def myfunc(item) when item == Const.something, do: Const.something + 5
        def myfunc(item) when item == Const.another, do: Const.another
      end

  """
  
 defmacro __using__(_opts) do
    quote do
      import Constants
    end
  end

  @doc "Define a constant"
  defmacro constant(name, value) do
    quote do
      defmacro unquote(name), do: unquote(value)
    end
  end

  @doc "Define a constant. An alias for constant"
  defmacro define(name, value) do
    quote do
      constant unquote(name), unquote(value)
    end
  end
end

This is quite cool! Would be nice if it was possible to require and alias at the same time, but I think I might have a play with this as the general way to do constants.

Well, in the “required” module you could implement a __using__/1 macro and use it from the requiring one. In that __using__/1 you then can of course require and alias at the same time.

Using such macros has still the same issue - you have opaque integers passing around at runtime - this makes it really hard to debug issues, especially if dealing with large numbers.

As to when do conversions - I spoke about boundaries of the system. By that I mean every time we receive data from outside or send it out - this means params from requests, database responses, etc. For example, when using ecto, you can provide a custom type to do the conversions for you (assuming encode and decode functions as before):

defmodule Constant do
  @behaviour Ecto.Type

  def type, do: :integer

  def cast(int) when is_integer(int), do: {:ok, decode(value)}
  def cast(atom) when is_atom(atom), do: {:ok, atom)
  def cast(_), do: :error

  def load(int) when is_integer(int), do: {:ok, decode(value)}
  def load(_), do: :error

  def dump(atom) when is_atom(atom), do: {:ok, encode(value)}
  def dump(_), do: :error
end

I would definitely go for the approach from @michalmuskala. One problem with maps is that it only supports one way conversion (converting a const into an integer). If you need to convert an integer into a const, you’ll have to build a reversal map. This can be easily done, even during compilation time, but then the code becomes as complex if not more than Michal’s version.

Moreover, I’m not completely sure whether this map is stored in the so called “constant pool”, and if it’s not, then the performance might suck. But even if this is not the case, my previous point stands, and I would personally go for Michal’s solution.

Using that approach, you could have something like:

defmodule Const do
  # Michal's snippet:
  values = [source_lvl1_api: 301023, ...]
  for {key, value} <- values do
    def encode(unquote(key)),   do: unquote(value)
    def decode(unquote(value)), do: unquote(key)
  end
end

And now you can do e.g. Const.encode(:source_lvl1_api), or Const.decode(301023) to perform atom ↔ integer conversions.

So what Michal is trying to tell you is that as soon as you take some input from say HTTP request, or the database, you invoke Const.decode to convert it into an atom. Then in the rest of your code, you just deal with atoms (e.g. :source_lvl1_api), so the code is ridden of magical numbers. Likewise, if you need to send a response to some client, or store to the database, you perform Const.encode to convert the atom into a corresponding integer.

I ended up going with the idea from @michalmuskala - it makes sense to use atoms everywhere I can, then just have integers in the DB and frontend client.

defmodule API.Const do
  @root_dir       File.cwd!
  @consts_dir     Path.join(~w(#{@root_dir} lib api common constants))

  consts = Path.wildcard("#{@consts_dir}/**/*.json")
           |> Enum.map(fn(filename) -> File.read!(filename) |> Poison.decode! end)
           |> Enum.reduce(fn(c, map) -> Map.merge(map, c) end)

  for {key, value} <- consts do
    def encode(unquote(String.to_atom(key))),   do: unquote(value)
    def decode(unquote(value)), do: unquote(String.to_atom(key))
  end
end

I decided to have a folder of JSON files, that way I can easily use it on the frontend as well (at the moment it runs some scripts to convert to JSON files from PHP)

Are there any issues doing it this way?

I was thinking of prepending the name of the file to each key in the JSON file to help namespace it a bit, so system.json would be

{
  "SOURCE_LVL1_API": 301023,
  "SOURCE_LVL1_HTTP": 301024,
  "SOURCE_LVL1_EMAIL": 301025,
  "SOURCE_LVL1_SMS": 301026,
  "SOURCE_LVL1_UNKNOWN": 301027
}

and would end up being

%{
  :SYSTEM_SOURCE_LVL1_API => 301023,
  :SYSTEM_SOURCE_LVL1_HTTP => 301024,
  :SYSTEM_SOURCE_LVL1_EMAIL => 301025,
  :SYSTEM_SOURCE_LVL1_SMS => 301026,
  :SYSTEM_SOURCE_LVL1_UNKNOWN => 301027
}

Not sure though!