When to use perform_action("type", ...) vs perform_type(...)

Questions / Help
1

What is the community guidelines on when you should pattern match a function vs when you should write its own? Eg:

Style 1

Extract something to match on and pass all the data down:

def perform_action(%{action: type} = data), do: perform_action(type, data)
def perform_action(:save, data), do: :ok
def perform_action(:delete, data), do: :ok
def perform_action(:revert, data), do: :ok
def perform_action(_, data), do: :error

Pros

  • Easier to organize like with like?
  • Allows flexibility in what data should contain at each handler
    • Including error handling (checking for required keys, etc)

Cons

  • Only one @doc block allowed
  • All functions are public (may not really be an issue)

Style 2

Get type and then call specific:

def perform_action(%{action: type} = data) do
  case type do
    :save -> perform_save(data)
    :delete -> perform_delete(data)
    :revert -> perform_delete(data)
    _ -> :error
  end
end

def perform_save(data), do: :ok
def perform_delete(data), do: :ok
def perform_revert(data), do: :ok

Pros

  • Can have per-function @doc blocks
  • Still flexible in what “downstream” functions accept and error handling is local to them
  • Probably easier to write “sub match” function headers for each action (eg: perform_save(%{sneaky: true} = data))
  • Specific functions can be private if needed
  • Lists all supported operations in one place?

Cons

  • First case could get very large?

Style 3

Extract specific data from top and pass down to functions:

def perform_action(%{action: type} = data) do
  case type do
    :save -> perform_save(data.id, data.content)
    :delete -> perform_delete(data.id)
    :revert -> perform_delete(data.id, data.date)
    _ -> :error
  end
end
def perform_save(id, content), do: :ok
def perform_delete(id), do: :ok
def perform_delete(id, date), do: :ok

Pros

  • @doc per function
  • More explicit interfaces, very obvious that save needs id + content.

Cons

  • Puts “must have key” checks in first function, which might bloat,
    • Though it could match on the type before dispatching to the specific
      function (but maybe thats just #1 with more steps…

From this extremely scientific research, it seems that #2 is maybe the best? Mostly because you can have per-function docs (though if they’re private this doesn’t actually count, @docp when?) It also seems really common with OTP to just have one named function and match on literally everything too but this is probably more a side effect of needing a generic interface - not intentionally blessed?

I am sure the most appropriate answer is, “well it depends.”, but discarding that, what does the community like to write?

2

In this particular case they all could be variants of the same function pattern matching on action type right in the function head

def perform_action(%{action: :save} = data), do: :ok
def perform_action(%{action: :delete} = data), do: :ok
def perform_action(%{action: :revert} = data), do: :ok
def perform_action(data), do: :error

But to your question:
You probably have seen examples when private functions have the same name as public function but prefixed with do_ like

def perform_action(%{action: type} = data)  do
  do_perform_action(type, data)
end

defp do_perform_action(:save, data), do: ...
...

So that pattern is discouraged now[0] in favor of coming up with a better name (however, you still could find examples even in the source code of elixir, e.g. here)

That would make something in between Style 1 and Style 2
Name public and private functions differently from each other, but all private functions could have the same name.

def perform(%{action: type} = data), do: perform_action(type, data)

defp perform_action(:save, data), do: :ok
defp perform_action(:delete, data), do: :ok
defp perform_action(:revert, data), do: :ok
defp perform_action(_, data), do: :error

[0] - Add describe and module attributes by blatyo · Pull Request #9181 · elixir-lang/elixir · GitHub

2 Likes
3

If you’re dispatching based on external data (like a message) use pattern matching, but if you’re implementing known domain behaviour, definitely use a function for the various reasons you mentioned. Concrete concepts should have concrete names like Accounts.login_user or for CRUD operations Accounts.update_user. This way, you’re explicitly naming things your app does. This is especially true with CRUD because it’s highly possible that not all of your entities will support the full set of CRUD operations, eg, maybe you can only hide a post but never actually delete it. This would be far less discoverable if you’re passing atoms to a generic perform_action function (this is one thing I don’t miss about ORMs that automatically give you all CRUD actions whether you want them or not). On the other hand, things like GenServer use pattern matching as they are providing an extremely generic API to an abstract concept and, as you likely know, it’s super common to wrap their implementations in concrete function calls.

4 Likes