Passing functions between processes

What you’re describing sounds like a behavior. Behaviors specify @callback functions that any module that uses the behavior needs to define. You’ll frequently see those implementations annotated with @impl true or @impl WhateverTheBehaviorModuleIs.

GenServer and Plug are both good examples of this style.

second the look up behaviours recommendation.

Elixir module/function calls are duck typed. You can do something like this:

module = SomeModuleName
module.some_function()

and there there’s no compile time checking to see if some_function is valid in the SomeModuleName module namespace.

you can pass closures between nodes. Just do it!

1.Make two sname’d elixir nodes (iex --sname foo --cookie bar; iex --sname baz --cookie bar),
2. connect them with Node.connect/1
3. on baz, do the following:

spawn(fn ->
  lambda = receive do f -> f end
  IO.puts(lambda(1))
end)
|> Process.register(Catcher)

then on foo do the following:

lambda = fn x -> x + 1 end
Node.spawn(:baz@<whatever-your-hostname-is>, fn ->
  send(Catcher, lambda)
end)

and of course, it will work. Dirty little secret is that Node.spawn/2 is just by itself sending a lambda and running it on the other side so that sending lambdas in general should work should maybe not be surprising!

If you want to go into even more “BEAM is awesome” territory, you can pickle your lambda using :erlang.term_to_binary, send it over the internet to another node, then unpickle the lambda using :erlang.binary_to_term, and it will just work™ (with some exceptions, like pids won’t be translated correctly)

Sending a function from one node to another is very sensitive and needs to be done very carefully. So doing a Node.spawn/2 with a fn or sending a fn requires that the module in which the fn is defined is already loaded on the other node. It also demands that it is exactly the same version of the module without any changes and preferably the same compiled code.

The reason for this is that when a module is compiled an md5 checksum of the code is included in the module definition. Internally a function includes the name of the module in which it is defined and that modules checksum. When it is called the module name is used to find the function code and the checksums are compared, and they have to be the same.

Welcome to the forum!

That ceremony could overcomplicate things at least initially as I suspect that there already is a GenServer callback module implementation that does most of the work:

I’ve got a pretty generic GenServer that I’ve created that I want to use in a few contexts.

What it sounds like is that the GenServer callback module in itself needs further specialization by being bound on yet another separate callback module - within this discussion the strategy callback module.

So really the essence here is that a callback module is simply the name of a module that promises to implement certain functions that the behaviour module will invoke on it.

The name of the strategy callback module can be passed as one of the arguments to the init/1 callback and stored in the GenServer state, e.g.:

  def init(args) do
    with {:ok, strategy} <- Keyword.fetch(args, :strategy) do
      {:ok, %{strategy: strategy}}
    else
      _ ->
        {:stop, :badarg}
    end
  end

Then later the function can be called as (provided the GenServer state is bound to state):

result = state.strategy.the_fun(the_arg)

or

result = apply(state.strategy, :the_fun, [the_arg])

Kernel.apply/2

At the simplest level I would compare behaviours to the strategy pattern though there are also elements of the template method pattern.

Awesome, thank you everyone for the good insights!