BenSchZA
Creating a GenServer `handle_call` macro / decorator
I’ve created a custom GenServer macro, to abstract the logic from the user of a project I’m working on, Cadex. It’s used for modelling and simulating basic differential equation based models and eventually complex systems.
I’ve been experimenting with different ways I can create state update functions like below, and make it a bit cleaner - so the user only has to implement the core logic. Essentially I want to take the handle_call function and insert code before and after, adapt the function interface, but I’m struggling to get my head around it. You can see my WIP here: cadex/lib/cadex at robots-marbles-7 · BenSchZA/cadex · GitHub in decorators.ex and model.ex.
def handle_call(
{:update, var},
_from,
state = %Cadex.Types.State{current: current, delta: delta}
)
when var == :box_A do
increment =
&(&1 +
cond do
current[var] > current[:box_B] -> -1
current[var] < current[:box_B] -> 1
true -> 0
end)
delta_ = %{var => increment}
state_ =
state
|> Map.put(:delta, Map.merge(delta, delta_))
{
:reply,
state_,
state_
}
end
Rather something cleaner like this:
@state_update(:box_A)
def update_box_A(
{:update, var},
state = %Cadex.Types.State{current: current, delta: delta}
) do
increment =
&(&1 +
cond do
current[var] > current[:box_B] -> -1
current[var] < current[:box_B] -> 1
true -> 0
end)
{var: increment}
end
In the GenServer macro, I’d then like to insert the rest of the code, and make sure the handle_call behaviour(?) is still implemented correctly and returns the right result. Is this possible?
I think I’ve messed around enough trying to implement a solution, and maybe some feedback would help me on my way! Appreciate any guidance ![]()
Marked As Solved
lucaong
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).
Also Liked
al2o3cr
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.
LukeWood
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
ityonemo
If you want a gen_statem that looks like genserver, I wrote StateServer — state_server v0.4.10
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









