Command Pattern via TCP

Now, final question on the subject (thanks all for your help, by the way): why do I need to remove the _build directory to trigger the @on_load hook? Shouldn’t that trigger when a module is loaded, and not when compiled?

I had discounted this in the beginning, but.. it’s brilliant. It works across compilation because the VM will not be stopped. It’s pretty much exactly my use case and it’s of a crazy simplicity.

Too bad it doesn’t support an update method but I don’t strictly need it, I’ll keep it flat: {:command, cmd_name} as key to avoid clashes, and the module as value. Brilliant.

I’m trying with ETS tables. There’s something I don’t get.. I create the table in the Command module, as soon as it’s loaded:

  @on_load :init
  def init() do
    res = :ets.new(:commands, [
      :named_table,
      :ordered_set,
      :public,
      {:read_concurrency, true},
      {:write_concurrency, true}
    ])
    whereis = :ets.whereis(:commands)
    content = :ets.tab2list(:commands)
    Logger.debug("table created: #{inspect(res)} #{inspect(whereis)} #{inspect(content)}")
  end

This works fine:

21:45:58.988 [debug] table created: :commands #Reference<0.2865878229.9043973.175739> []

The __using__ macro is like this now, with a Process.sleep to make sure the ETS table is setup at that point:

defmacro __using__(opts) do
    quote do
      @behaviour Command

      @on_load :register_command

      def register_command() do
        Process.sleep(5000)
        Command.register_command(__MODULE__, unquote(opts))
      end

      def parse_args(_cmd_args), do: {:ok, nil}
      defoverridable [parse_args: 1]
    end
  end

And then in the register_command, I try to insert:

  def register_command(module, cmd_opts) do
    Logger.debug("register_command: #{module} #{inspect(cmd_opts)}")
    cmd_name = Keyword.fetch!(cmd_opts, :name)
    :ets.insert(:commands, {cmd_name, module})
  end

But this, after the 5 seconds, crashes:

21:53:54.865 [warn]  The on_load function for module Elixir.Commands.Info returned:
{:badarg,
 [
   {:ets, :insert, [:commands, {"info", Commands.Info}],
    [error_info: %{cause: :id, module: :erl_stdlib_errors}]},
   {Command, :register_command, 2, [file: 'lib/command.ex', line: 60]},
   {:code_server, :"-handle_on_load/5-fun-0-", 1,
    [file: 'code_server.erl', ...]}
 ]}

21:53:54.858 [error] Process #PID<0.211.0> raised an exception
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: the table identifier does not refer to an existing ETS table

    (stdlib 3.15.2) :ets.insert(:commands, {"info", Commands.Info})
    lib/command.ex:60: Command.register_command/2
    (kernel 8.0.2) code_server.erl:1317: anonymous fn/1 in :code_server.handle_on_load/5

How does the table name, :commands, not refer to an existing ETS table? I don’t get. Is this because it’s happening at compile time and when the compilation finishes, the ETS table dies?

Ah.. nothing. It can’t be updated.

I’m having trouble with the set_env, as it doesn’t have an update method so I have race conditions (modules are loaded in parallel with on_load executions, it seems; maybe I can find some way to have on_load block the whole loading until it’s done).

So I’m thinking about alternatives. Ets tables etc, would work. But your idea is interesting @al2o3cr - an “attribute map” of the module? I need to try this

Essentially I still prefer to keep commands as separate files, and to register them automatically on load; it just seems cleaner (also works for hot code loading I think, as then the module is re-loaded and overwrites its entry in the command map). But your suggestion might fit nicely in my architecture.

Consider the simplest thing that could work: listing the mapping from command to handler atom explicitly.

  @handlers %{
    "foo" => Commands.Foo,
    "bar" => Commands.Bar,
    # etc
  }
  defp parse!(_state, [cmd | opts]) do
    case Map.fetch(@handlers, cmd) do
      {:ok, mod} -> {:ok, {mod, opts}}
      :error -> {:ok, {:echo, "#{cmd}: UNKNOWN_COMMAND"}}
    end
  end

This approach also has logical extension points for useful things:

• broadening the possible keys of the map to things like Regexes would allow for “partial match” commands
• broadening the possible values of the map to {module, baked_in_opts} lets one “command module” serve multiple external commands

One downside is that the command → module mapping can get quite long; consider extracting parts of it to functions and combining them at compile-time to reduce clutter.

Worth looking into persistent_term for storing the map - an Agent still forces every access through a single thread.

Looks like I was subtly wrong about ! convention:

But I would also say “don’t put a ! just because something can error”; I would say non-bang functions can raise on “programmer fault” (something analogous to :badarg); but should not raise on “user fault”.

Use application.put_env and application.get_env instead of an agent, it doesn’t need to be supervised, you don’t have to worry about it going down, etc.

Functions that end in ! by convention signify that they are a raising equivalent of a function that emits ok/error tuples

In my use case I have few ten of messages. Each message has it own struct but the serialization, deserialization is perform on the message module as its define the message ID for a given command.

Thanks! Essentially with the on_load, I’m not using string.to_atom anymore. I’m actually using an Agent as a key-value store (string → module as you also suggested). Eventually I’ll need a bit of a smarter key-value store (a treemap for example, if I want to support partial matching of command names, eg “rem” instead of “removefile”).

Nitpicky: parse should not be parse!

Can you explain why? In the “dynamic dispatch” tutorials they used it so I used it too, but it isn’t clear to me what it is or when it should be used instead..