Dealing with private and public function default conflicts

Questions / Help
,
1

I wanted to see how others deal with private and public function defaults conflict. In my context I like to have public functions that take the current_user from the request what ever other arguments are needed with a “matching” private function that only takes the arguments after the public function does some authorization.

here is a quick example of update user

# user context
def update_user(%User{} = current_user, %UpdateUser{} = update_user) do
    with :ok <- authorize(:update_user, current_user, update_user),
        {:ok, updated_user} <- update_user(update_user) do
        # some logic
    end
end

defp update_user(%UpdateUser{} = update_user) do
  # some logic
end

This works great 95% of the time but sometimes certain functions need to have default parameters

def list_company_users(%User{} = current_user, company_id, filters \\ %{}) do
    # some logic
end

defp list_company_users(company_id, filters) do 
  # some logic
end

For situations like this there is a conflict of having a private and a public function
defp list_company_users/2 conflicts with defaults from list_company_users/3

As a hacky workaround I made the arguments of the private function a tuple.

defp list_company_users({company_id, filters}) do 
  # some logic
end

I was curious if anyone else used a similar pattern and what solution they’ve taken when running into this issue.

1 Like
2

Personally I’d use different names for the private functions. To add to this I know _function is pretty common for private, personally I use function/do_function

def update_user
defp do_update_user

Anything will work as long as you’re consistent though then you don’t have to go check the def.

7 Likes
3

Seconded, I use the do_* private functions notations myself. Mostly because I have no better idea. :smiley:

3 Likes
4

It seems that do_* has become a convention :grinning_face_with_smiling_eyes:
By the way, I follow this convention, too.

2 Likes
5

There is no way to detect if You call list_company_users/3 without filter, and list_company_users/2

You might add guard clauses…

# Use when is_binary if You use binary id.
def list_company_users(%User{} = current_user, company_id, filters \\ %{}) when is_integer(company_id) do
    # some logic
end

defp list_company_users(company_id, filters) when is_map(filters) do 
  # some logic
end

I also prefer do_* for private functions…

You might also check how to use function’s signature

1 Like
6

Personally I would recommend against prefixing them with do_ most of the times.
If you can find a more descriptive name, use it. If you cannot, or it is too cumbersome, use do_ then.
It does not matter if the name of the function is long, it is private anyway.

In Elixir core the use of do_ has been discouraged, and while at the beginning it was a bit annoying once you get used it, it pays off.

In your first example, I would refactor it, by swapping the arguments of the arity-2 function. I hope you can see the benefit of it.

def update_user(%UpdateUser{} = update_user, %User{} = current_user) do
    with :ok <- authorize(:update_user, current_user, update_user),
        {:ok, updated_user} <- update_user(update_user) do
        # some logic
    end
end

defp update_user(%UpdateUser{} = update_user) do
  # some logic
end

As for your second example, I will rename your second function to a more meaningful name.

def list_company_users(%User{} = current_user, company_id, filters \\ %{}) do
    # some logic
end

defp filter_company_users(company_id, filters) do 
  # some logic
end
7

Thank you for all the replies. It does seem the Elixir community has a convention of doing do_* for private functions. I’m going to try it out and see how it feels.

Thank you everyone for the replies!

1 Like
8

This is one of my favorite patterns, the _guarded suffix. You do all your guard checks in your public function, and you delegate to a private one and call it recursively if needed, without checking for a guard again and increasing performance.

This is the current implementation for Keyword.update/4

  @spec update(t, key, default :: value, (existing_value :: value -> new_value :: value)) :: t
  def update(keywords, key, default, fun)
      when is_list(keywords) and is_atom(key) and is_function(fun, 1) do
    update_guarded(keywords, key, default, fun)
  end

  defp update_guarded([{key, value} | keywords], key, _default, fun) do
    [{key, fun.(value)} | delete(keywords, key)]
  end

  defp update_guarded([{_, _} = pair | keywords], key, default, fun) do
    [pair | update_guarded(keywords, key, default, fun)]
  end

  defp update_guarded([], key, default, _fun) do
    [{key, default}]
  end
2 Likes
9

Wow, this is really nice and new for me. I’ve used the same concept, but when it is explicitly named, looks much better.

1 Like