How do define behaviours that have callbacks with optional parameters?

Chat / Discussions
,
1

Background

So I have a behaviour that has some functions with optional parameters and I want a way to make them more readable:

  @type order :: %{
          String.t() => String.t(),
          String.t() => String.t(),
          String.t() => non_neg_integer,
          String.t() => non_neg_integer,
          String.t() => non_neg_integer
        }
@type deps :: keyword

@callback place_order(order) ::
              {:ok, order_id}
              | {:error, :order_already_placed | :invalid_item_id, order}
@callback place_order(order, deps) ::
              {:ok, order_id}
              | {:error, :order_already_placed | :invalid_item_id, order}

In both cases my function will return exactly the same, the only difference is that I can either pass a keyword of dependencies, in which case the implementation of the behaviour will use, or I can leave it blank, in which case the implementation will use something by default.

The issue

The issue here is that I have a lot of repetition I dont need. I could just define more new types, one for @type ok_repsonse and one for @type error_response but not only is that not really needed, it also adds to the complexity and adds extra levels of indirection.

I was hoping there was something more like an optional keyword for callback parameters I could use:

@callback place_order(order, optional(deps)) ::
  {:ok, order_id} 
  | {:error, :order_already_placed | :invalid_item_id, order}

Question

How can I define optional parameters in a callback inside a behaviour without duplicating everything?

2

Afaik what you’re looking for is not possible at the moment. Packages like ecto only put the full parameter version of their functions on behaviours, while the concrete implementations do implement optional params. In a recent experiment with mocking Ecto.Repo using Mox I found this to be unsatisfying, as one needs to not skip optional parameters in lots of places to not get in trouble with Mox. On the other hand the behaviour (/interface) clearly states that those functions need to have certain arguments, and one shouldn’t depend on the concrete implementation, but only the interface, when intending to switch out multiple implementations.

3 Likes
3

I am not sure, but the callback with all arguments should be enough.

If you implement the callback you will do something like that:

def place_order(order, opts \\ []) do ...

And for this you just needs:

@callback place_order(order, deps) ::
              {:ok, order_id}
              | {:error, :order_already_placed | :invalid_item_id, order}
4

But then if I do that, Dialyzer and Hammox/Mox will complain saying I am not respecting the behaviour/interface I have defined and will error out. This is what I am trying to avoid.

5

One potential solution might be separating optional params from the concrete implementations:

# Behaviour
@callback my_fun(atom, keyword) :: atom

# Impl
def my_fun(atom, opts), do: Keyword.get(opts, :test, atom)

# Module in front of impl
def my_fun(impl, atom, opts \\ []), do: impl.my_fun(atom, opts)

This way the simpler API is easily sharable via all concrete implementations of a smaller behaviour.

6

I am confused, could you give an example of how I could use this?
I don’t understand the

# Module in front of impl
def my_fun(impl, atom, opts \\ []), do: impl.my_fun(atom, opts)

function.

How would you invoke the implementation of the callback?

MyImplModule.my_fun(MyImplModule, order)

and if I want to pass in dependencies:

MyImplModule.my_fun(MyImplModule, order, deps)

???

7 
defmodule Http do
  def get(client, url, opts \\ []) do
    client.get(url, opts)
  end
end

defmodule Http.Client do
  @callback get(URI.t | String.t, keyword) :: term
end

defmodule Http.Httpoison do
  @behaviour Http.Client
  def get(url, opts) do
    HTTPoison.get(url, opts)
  end
end

You’d never actually call functions on Http.Httpoison directly, but only though Http.

3 Likes
8

Alright, so I understand you would use a Mox that obeys the HttpClient behaviour which would replace the Httppoison client.

Now however this becomes an issue of boundaries. Where is the boundary in your system?
If we take for example, the hexagonal architecture, your port would be the Http.Client and your adapter Http.Httpoison, which means your boundary is Http.client (because it is your port).

Basically, your are pushing your boundaries one level away, adding an intermediary module. I guess technically it works, but it does seem to add quite a bit of complexity.

9

Correct. I’m not so sure about the complexity though. Yes, it’s “slightly more” code and especially a module more. Yes, you need to deal with passing the implementation as e.g. a parameter. But you’ll get lesser complexity for any of your implementations, as they don’t need to deal with any optionality/function heads and can just provide an implementation for a clean and simple behaviour. The part dealing with your optional params becomes part of your functional core and is therefore easier to test.

Basically – for the amount of code you need to have – this approach moves the line between your core and the ugly outside world further out / makes the edge smaller.

2 Likes