Creating a GenServer `handle_call` macro / decorator

If I understand, you want to allow the user of your library to specify how the state should be updated, without requiring them to implement the whole GenServer and without leaking private implementation details that should not affect the user. Is that correct?

If so, initially leave aside the GenServer and its state and think about a functional core for the state update logic. I do not understand the details of your example, but it seems that the user should specify how to update the :delta given some information in var and current. If that is true, you could let the user supply a module that fulfills a specified behavior, something like this:

# Behavior (adjust the types to the correct ones)
defmodule YourBehaviour do
  @callback update(var, current) :: delta
end

# User defined functional implementation
defmodule UserImplementation do
  @behaviour YourBehaviour

  @impl true
  def update(var, current) do
    # compute and return delta
  end
end

# Provide the implementation, something like:
{:ok, pid} = YourLibrary.start_link(impl: UserImplementation)

I might have gotten the details wrong, but the important thing is that you define a functional behavior so that the user defined functions receive all the needed data and no more than that, and return the updated value.

Your GenServer will then maintain the state and use the module supplier by the user to update it. This way, the user does not access implementation details or private data structures, and your GenServer logic can be tested with your own test implementation. Runtime concerns like handling concurrency or supervision are left outside of the functional core. Also, no macro is needed.

The GenServer is a runtime concern that is better separating from the actual update logic. This popular blog post elaborates more on the idea (the author, @sasajuric, hangs out in this forum).

If I understand, you want to allow the user of your library to specify how the state should be updated, without requiring them to implement the whole GenServer and without leaking private implementation details that should not affect the user. Is that correct?

That’s correct, and behaviors look like exactly what I need I’m going to give this a try, and see if I understand how the core logic and GenServer are then used together. I’ll come back for another review.

Also check out gen_statem - it’s an example of an abstraction on top of the GenServer behavior that abstracts away state-updating and event routing.

That library is almost exactly what I need! I might even try build on top of it.

I wrote a library to do this recently -

I didn’t like how it turned out so I never pushed forward - but you might find some value in the source code

https://github.com/LukeWood/GenClient

If you want a gen_statem that looks like genserver, I wrote StateServer — state_server v0.4.10

I joined the Elixir Forum just over a week ago, and already I can say the Elixir community is one of the best! Thanks for all the suggestions, going to accept @lucaong 's answer, but they’ve all helped answer my question.

I’m excited to keep learning - just got a client wanting a data ETL pipeline, that is going to be the perfect match for the Elixir/Phoenix ecosystem, GenServer, GenStage, all the rest. First opportunity to use Elixir in production

After refactoring to use behaviours:

A model is defined.

defmodule Marbles do
  @behaviour Cadex.Behaviour

  @initial_conditions %{
    box_A: 11,
    box_B: 0
  }

  @partial_state_update_blocks [
    %Cadex.Types.PartialStateUpdateBlock{
      policies: [
        :robot_1,
        :robot_2
      ],
      variables: [
        :box_A,
        :box_B
      ]
    }
  ]

  @simulation_parameters %Cadex.Types.SimulationParameters{
    T: 10
  }

  @impl true
  def config do
    %Cadex.Types.State{
      sim: %{
        simulation_parameters: @simulation_parameters,
        partial_state_update_blocks: @partial_state_update_blocks
      },
      current: @initial_conditions
    }
  end

  @impl true
  def update(var = :box_A, _state = %Cadex.Types.State{current: current}) do
    increment =
      &(&1 +
          cond do
            current[var] > current[:box_B] -> -1
            current[var] < current[:box_B] -> 1
            true -> 0
          end)

    {:ok, increment}
  end

  @impl true
  def update(var = :box_B, _state = %Cadex.Types.State{current: current}) do
    increment =
      &(&1 +
          cond do
            current[var] > current[:box_A] -> -1
            current[var] < current[:box_A] -> 1
            true -> 0
          end)

    {:ok, increment}
  end
end

The model is run (down the line there will be settings for Monte carlo simulations etc.)

{:ok, pid} = Cadex.start(Marbles)
Cadex.update(:box_A)
Cadex.update(:box_B)
state = Cadex.state()

# Or, to run a full model loop
Cadex.run(optional_args)

This looks much better.