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
defdelegate foo(), to: A
defoverridable [foo: 0]
def foo(), do: "Foo"
defmodule B do
@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__
module B do
# has function bar, overwrites foo, exports all in __using__
module C do
# has bar() and B's version of foo()
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.
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