threeaccents
Dealing with private and public function default conflicts
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.
Trending in Questions
Other Trending 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
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First 8 of 8 Posts
sanswork
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.
dimitarvp
Seconded, I use the
do_*private functions notations myself. Mostly because I have no better idea.Aetherus
It seems that
do_*has become a conventionBy the way, I follow this convention, too.
kokolegorille
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…
I also prefer do_* for private functions…
You might also check how to use function’s signature
eksperimental
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.
As for your second example, I will rename your second function to a more meaningful name.
threeaccents
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!
eksperimental
This is one of my favorite patterns, the
_guardedsuffix. 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
dmitrykleymenov
Wow, this is really nice and new for me. I’ve used the same concept, but when it is explicitly named, looks much better.