Call external module funcs inside generated functions in macro

alichoopani

hello everyone.
I am trying to learn metaprogramming and start with simple project. in this road I this weird situation.
I want to implement interface like action_fallback macro in Phoenix controller(inside UseSample module).


defmodule GuardModule do
  def test() do
    IO.inspect("TEST")
  end
end

defmodule Sample do

  defmacro guard(module_name) do
    quote do
      @guard unquote(module_name)
    end
  end

  defmacro __using__(_opts) do
    quote do
      import unquote(__MODULE__)
      Module.register_attribute(__MODULE__, :guard, accumulate: :false, persist: :false)

      @before_compile unquote(__MODULE__)
    end
  end

  defmacro __before_compile__(env) do
    custom_guard = Module.get_attribute(env.module, :guard)
    custom_guard.test()
    # quote do
    #   def test_inside_use_sample() do
    #     custom_guard.test()
    #   end
    # end
  end
end

defmodule UseSample do
  use Sample

  guard GuardModule
end

now I have some questions.

in Sample.__before_compile__ macro i can call external module functions. but i can’t generate function that call this external function inside its body(commented section not compile). how can I do that?
in this situation GuardModule compiles before others because it’s in the beginning of file. how can I force elixir compiler to compile this module before Sample module?
and finally am i have right solving strategy for this problem or should do something else?

thanks a lot.

2 comments

#metaprogramming #quote #macro

0 985 2

2023-01-25 23:09:59 UTC

Showing Posts 1 to 2

Show Best Posts
Show All (oldest first)
Show All (newest first)

hst337

You forgot unquote

quote do
  def test_inside_use_sample() do
    unquote(custom_guard.test())
    # or like this
    unquote(custom_guard),test()
  end
end

Try using higher order functions

Post #1

rvirding

Creator of Erlang

There are no problems for you to load in your version of that module again. There is no way to stop anyone from loading in new versions of any module. However there are some properties of code handling you should be aware of:

There can at most be 2 versions of a module at the same time, the current and the old. When a new version is loaded in the old version is automatically and irrevocably deleted, the current version becomes the “new” old and the the new one becomes the “new” current.
The system doesn’t try and be smart and say that if you already have the version of the module loaded it won’t reloaded It does what you tell it to.
The code handling also kills all the processes using the old version of a module when that is deleted.
This leads to some fun things. If you reload a module twice you are guaranteed to kill all processes running it regardless of which version they are running.
When you call a function in a module which version you call depends on how it is called. If you make a local call you always get the same version while if you make a fully qualified call, Module.function, you always get a the current version. There is no way to explicitly call functions in the old versions from the “outside”.