I believe that you should add also @behaviour attribute into __using__ macro, so code would look cleaner. For now somebody reading __before_compile__ would not know from where build/1 comes and with behaviour you could require it.

The problem is that you are already defining build/1 without noticing that!

Look that when you write such code in iex:

defmodule Example do
  def sample(first_arg, second_arg \\ nil), do: {first_arg, second_arg}
end

and after it you wrote Example. + hit <Tab> (for printing suggestions) then you would see:

> Example.sample
sample/1    sample/2

Which means you have defined sample/1 as well as sample/2 by just one function definition (using default argument). It’s working like:

defmodule Example do
  def sample(first_arg), do: sample(first_arg, nil)
  def sample(first_arg, second_arg), do: {first_arg, second_arg}
end

So your problem is build/1 function definition inside __before_compile__ - it’s why compiler does not show you any warning. Notice that when you remove default value you should see:

warning: function build/1 required by behaviour Obramax.Factory is not implemented (in module Obramax.ChannelsFactory)

Yeah or … just rename one function.

For example in __before_compile__ you can have full_build/1 and full_build/2 and in behaviour you would have only build/1.

Also notice that build/1 from __before_compile__ conflicts with build/1 from behaviour, so in fact one of them (if I understand it correctly build/1 from behaviour) is never used.

You can find all you need in Module docs: Compile callbacks.

Thanks for clarifying that. I put build/1 in __before_compile__ to throw an error instead of letting the process hang when the function call can’t pattern match. For example, if you use an atom that has no function definition: build(:i_dont_exist)).

And now I know why it hangs. When a build/1 call can’t pattern match, it falls through to build/2. But in reality, it’s falling through to build/1 that’s automatically expanded due to the default argument, which again calls build/2 with the unknown atom as the first argument, and a list as the second argument: build(:i_dont_exist, []).

Then build/2 calls build/1 again (the expanded one, from the default argument):

def build(factory_name, attributes) do
  factory_name
  |> build() # <-- here
  |> struct(attributes)
end

… and the process keeps repeating.

Thanks! This whole thread has been illuminating. I learned a bunch of stuff today!