Typespec for a type implementing behaviour

Questions / Help
,
1

Let’s say I have a behaviour MyBehaviour and a function that may return any module implementing that behaviour. Is it possible to write a type spec for that?

For example (pseudo-code):

defmodule MyBehaviour do
  @callback say_hello() :: String.t()
end

defmodule MyBehaviourImplA do
  @behaviour MyBehaviour
  def say_hello(), do: "Hello from A"
end

defmodule MyBehaviourImplB do
  @behaviour MyBehaviour
  def say_hello(), do: "Hello from B"
end

defmodule ThisIsWhereTheQuestionComesIn do
  @spec get_module_implementing_behaviour() :: ?????
  def get_module_implementing_behaviour(), do: MyBehaviourImplA
end

I want to specify that ThisIsWhereTheQuestionComesIn.get_module_implementing_behaviour/0 could return either MyBehaviourImplA or MyBehaviourImplB (or indeed any module that implements that behaviour).

My use case is for a configurable adapter pattern; I want to write a function that returns whatever the currently configured adapter is.

Thanks as always!

1 Like
2

I think all you can do is:

@spec get_module_implementing_behaviour() :: module()
3 Likes
3

Thanks, that’s what I’ve done so far. If anyone knows of a Better Way™ I’d appreciate it!

I’ve also consider just smashing in the actual module as a type that is being returned. It means one more thing to change in the code but in my case it doesn’t make a huge amount of difference (at least not yet). E.g.

@spec get_module_implementing_behaviour() :: MyBehaviourImplA
4

There is not. And this is something very much on my wish list for better BEAM types.

If you’re willing to out some elbow grease into it, with elixir you can build limited compile-time checks for this (with Code.ensure_compiled and module.__info__(: attributes), Kernel.function_exported?), or if you have a runtime assigned module variable, you could do that at runtime too (maybe only in :test and :dev ends)

One place where I do this, sometimes I EctoEnum modules so that I can select adapter modules. Immediately after the defenum declaration, i run a series of compile time checks to guarantee that the modules persisted in my db are comformant to the runtime’s expectations.

5

This will never be possible in erlang/elixir. Modules can be defined at runtime, so a compiletime check can by definition not be aware of all possible modules implementing a behaviour / assert if a given module does implement a behaviour. Any module might not even exist at compile time.

6

huh?

Of course a compile time check won’t be aware of runtime modules implementing a behaviour, but suppose we had a module Beh which defined callback my_fun(integer) :: integer

Then doing:

@spec foo(module(Beh)) :: integer
def foo(mod) do
  mod.my_fun("bar")
end

should raise some eyebrows

as should:

@spec foo(module(Beh)) :: String.t
def foo(mod) do
  mod.my_fun(4)
end

If some runtime-defined module breaks this contract and gets passed into foo/1 then dialyzer should not really care.

7

I was looking for a similar solution, in the end I did something similar:

defmodule MyBehaviour do
  # Define a type for the behaviour
  @type t :: module()
  @callback say_hello() :: String.t()
end

defmodule MyBehaviourImplA do
  @behaviour MyBehaviour
  def say_hello(), do: "Hello from A"
end

defmodule MyBehaviourImplB do
  @behaviour MyBehaviour
  def say_hello(), do: "Hello from B"
end

defmodule ThisIsWhereTheQuestionComesIn do
  # Using the type of the behaviour module
  @spec get_module_implementing_behaviour() :: MyBehaviour.t
  def get_module_implementing_behaviour(), do: MyBehaviourImplA
end

Does not do much with the typechecks but maybe more readable than simple module or hardcode the exact module into the @spec :slight_smile:

8 Likes