Softknobs
Can a @callback behaviour call a private function inside the module that "uses" it?
Hi,
I can’t tell if this is related to Elixir itself or the implementation of the Phoenix.LiveComponent module (from LiveView) I am using. Also, I am not familiar with Behaviours yet and new to Elixir.
In my code, I tried to refactor this code (this is a simplified example):
defmodule My.Module do
use Phoenix.LiveComponent
# update is a behaviour (@callback) from LiveComponent,
# "assign" function adds values to the socket.assigns map
def update(assigns, socket) do
socket |> assign(:value, assigns.value)
end
to this:
defmodule My.Module do
use Phoenix.LiveComponent
# "assign" function adds values to the socket.assigns map
defp default_values(assigns, socket) do
socket |> assign(:value, assigns.value)
end
# update is a behaviour from LiveComponent
def update(assigns, socket) do
socket |> default_values(assigns)
end
The former code works, while the latter fails with an error (not Elixir) complaining that :value is not found in socket. But looking at the code, it is not true because default_values function adds :value to the socket just like the former code, socket |> assign(:value, assigns.value), did it.
Then I made default_values public instead of private, and the refactored code started working like the former version. I am a bit puzzled because if is a accessibility problem, I would have expected either:
- a compiler error telling the behaviour cannot access a private function inside the module that uses it
- a runtime error telling the function
default_valuesis undefined or private.
I did not expect the code would proceed “normally” ignoring the private function (or silently catching the problem, or whatever happens here…) leading to a crash later because, in the end, the function was not applied to the data.
Actually it worries me because in this particular case the program crashes later because some requirements are not met. This not always the case, and it would have been very hard to figure out one function was not applied without crashing in other situations.
Does anybody have an idea of what is happening in this case? Does it have to do with Elixir itself or could it be the way the “used” module is implemented?
Marked As Solved
lucaong
In other words, you might have misunderstood the pipe operator. The pipe operator performs the function call on the right side inserting the expression on the left side as the first argument.
This is equivalent to default_values(socket, assigns, socket), which won’t work because your default_values function takes only two arguments, the last of which is the socket.
The code posted above by @hauleth fixes this by defining default_values to take two arguments, the first of which is the socket. This way, the pipe operator will correctly introduce the socket argument.
Also Liked
hauleth
I am not sure how Yours code even compile as there is no default_values/3 function. This should work as expected:
# "assign" function adds values to the socket.assigns map
defp default_values(socket, assigns) do
socket |> assign(:value, assigns.value)
end
# update is a behaviour from LiveComponent
def update(assigns, socket) do
socket |> default_values(assigns)
end
lucaong
After the edit, your code still has the problem that you are defining default_values taking the socket as the last argument, while the pipe operator will insert it as the first.
As an additional note, you don’t necessarily have to use the pipe operator if you make a single call.
# This
foo |> bar(:something)
# Is equivalent to this
bar(foo, :something)
The situation where the pipe operator is useful is when you chain multiple calls, often transforming a data structure in a pipeline, so that your code flows in the right “direction”:
# This:
[1, 2, 3, 4, 5, 6, 7, 8, 9]
|> Enum.filter(&Integer.is_even/1)
|> Enum.map(fn x -> x * 2 end)
# Is the same as this:
Enum.map(
Enum.filter([1, 2, 3, 4, 5, 6, 7, 8, 9], &Integer.is_even/1),
fn x -> x * 2 end
)
# Except the first version is more readable,
# and makes it clear that we first filter, then map
lucaong
Welcome, and by the way, I definitely made this same mistake more frequently than I want to admit 
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"