Dynamically add module functions in __using__ macro

I’m pretty sure you can just import the parent module of the __using__ macro with import A inside the macro. For example, the Phoenix 1.3 generators create the following DataCase module:

defmodule MyApp.DataCase do

  using do
    quote do
      ...

      import MyApp.DataCase
    end
  end

  def errors_on(changeset) ...
end

So, all of the MyApp.DataCase functions will be auto imported into the scope of any module which calls use MyApp.DataCase.

Kernel — Elixir v1.20.2 has an example similar to what you want:

defmodule A do
  defmacro __using__(_opts) do
    quote do
      def foo, do: "Foo"

      defoverridable [foo: 0]
    end
  end
end

defmodule B do
  use A

  def foo do
    super() <> "Bar"
  end
end

And then in the shell

iex(1)> B.foo()
"FooBar"

Thanks for everyone’s replies.

@jswny I did try that but doesn’t work as you’d expect:

defmodule A do
  defmacro __using__(_opts) do
    quote do
      import A
    end
  end
  
  def foo(), do: "Foo"
end

defmodule B do
  use A
end

You can access A.foo() but not B.foo() Is this using do.. end DSL doing something special, compared to defmacro __using__(_)?

@idi527 defoverridable is indeed what I need to use to make an injected function overridable, but that’s only one part of the puzzle

My goal is to have the functions accessible on the original module, inject them into the module that’s using it via use and make them overridable:

import makes the functions from A available in module B but it doesn’t re-export them. Therefore functions in B can invoke the imported functions from A but you can’t call them from outside B. Its nothing to do with use, its how import works.

Overall, your last example isn’t a strong justification for use. Just import would be preferred because the intent is clearer. But I recognise your use case if presumably more complex that just import.

If basically you want to delegate a bunch of functions to another module, have them available as public functions on the new module and also make them overridable then perhaps the following would work? Its not considered good practise to do defining lots of functions in a quote block.

defmodule A do
  defmacro __using__(_opts) do
    quote do
      defdelegate foo(), to: A
      
      defoverridable [foo: 0]
    end
  end
  
  def foo(), do: "Foo"
end

defmodule B do
  use A
end

@kip Awesome, using defdelegate achieves the effect that I wanted! I’ve come across defdelegate before, but it didn’t occur to me that it would work just fine with defoverridable. Now it makes sense.

You were right in your previous post — I oversimplified my use case just for convenience. Ultimately I was wondering if this could work on multiple levels, e.g.

module A do
  # has function foo(), exports it in __using__
end

module B do
  use A
  # has function bar, overwrites foo, exports all in __using__
end

module C do
  use B
  # has bar() and B's version of foo()
end

If module D comes around and wants to inherit/extend module C, it doesn’t need to know about A or B at all. This approach tightly couples all the modules, but could be useful in some cases where it can be tolerated.

Thanks a lot for your help!

I sort of understand your intent but, to me (and maybe only me), this smells a bit of “making magic”. And the language “inherit/extend” makes it seem even more so.

I’ve found that a combination of partial importing of functions and the occasional use of defdelegate is a lot clearer to me because its explicit. One of the most frustrating things is to see a function call to a function whose definition you can’t find. The multiple indirect usees would, for me, make the intent obscure and quite frustrating.

To whom is that useful? You still need A and B to actually do things, so why not make that clear to the consuming code. The only reason for this I can imagine is that you want to own the implementation and do (or at least be able to do) changes on how A or B works. But then defdelegegate are imho the best option to be used within your intermediate consumer. Hiding the defdelegates in the implementation providing module is always a great indirection, which should have convincing reasoning for it’s usage.

@kip @LostKobrakai Yep, I definitely don’t disagree with you and import is much simpler and clearer for the majority of cases. I was purely interested in how could this be achieved from a metaprogramming standpoint. Whether this is a good or bad idea is a different topic, which I don’t intend to start