Can a @callback behaviour call a private function inside the module that "uses" it?

Questions / Help
,
1

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_values is 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?

2

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
1 Like
3

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.

3 Likes
4

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
1 Like
5

Sorry, I made a mistake when I extracted the code, I edited the original post, only the assigns is passed… nevertheless you spotted the problem that is now obvious: I inverted the the parameter of default_values/2. I feel a bit stupid now… :confused:
I guess at some point I managed to have this working “by accident” and made wrong assumptions about it.
Thank you @hauleth and @lucaong for pointing me in the right direction.

6

Welcome, and by the way, I definitely made this same mistake more frequently than I want to admit :slight_smile:

1 Like