I want to dynamically call a function from one of many modules which all use the same behaviour. I was thinking of doing something like this:
apply(String.to_existing_atom("Elixir.MyApp.#{module_name}", :some_func, [args]))
is this bad practice, is there a potential for exploit?
Unless args represent some sort of external input that is not being properly validated, I don’t think so. But this is valid for any other function call and not specific to apply.
I might be unaware of some undocumented behavior though, so I’d wait for other opinions on the matter.
yeah so args and module_name would be internal info
You can use Module.concat/2 as well:
MyApp
|> Module.concat(module_name)
|> apply(:some_func, [args])
Oh nice, that’s cool!
There are a lot of examples of using apply within Elixir itself and popular libraries, if you want to study how it can be used and if it is consistent with your usage. This is from the internal implementation of DynamicSupervisor.start_child/2
defp start_child(m, f, a) do
try do
apply(m, f, a)
catch
kind, reason ->
{:error, exit_reason(kind, reason, __STACKTRACE__)}
else
{:ok, pid, extra} when is_pid(pid) -> {:ok, pid, extra}
{:ok, pid} when is_pid(pid) -> {:ok, pid}
:ignore -> :ignore
{:error, _} = error -> error
other -> {:error, other}
end
end
From GenServer.whereis/1
def whereis({:via, mod, name}) do
case apply(mod, :whereis_name, [name]) do
pid when is_pid(pid) -> pid
:undefined -> nil
end
end
Task.start_link/1
def start_link(fun) when is_function(fun, 0) do
start_link(:erlang, :apply, [fun, []])
end
Postgrex.SimpleConnection, maintained by Elixir core members, I believe this is from an implementation of a behaviour:
def connect(_, %{state: {mod, mod_state}} = state) do
opts =
case Keyword.get(opts(mod), :configure) do
{module, fun, args} -> apply(module, fun, [opts(mod) | args])
fun when is_function(fun, 1) -> fun.(opts(mod))
nil -> opts(mod)
end
case Protocol.connect(opts) do
{:ok, protocol} ->
state = %{state | protocol: protocol}
with {:noreply, state, _} <- maybe_handle(mod, :handle_connect, [mod_state], state) do
{:ok, state}
end
{:error, reason} ->
if state.auto_reconnect do
{:backoff, state.reconnect_backoff, state}
else
{:stop, reason, state}
end
end
end
I feel like if you are using it with internal modules and functions then you are probably in the clear, but maybe there are gotchas I don’t know about. As @thiagomajesk said, if your args are unsafe then using apply probably doesn’t make a difference.
Thanks for the examples @msimonborg. I think my use is consistent with what you listed especially paired with String.to_existing_atom("MyApp.Context.#{module_name}") as this basically serves as an existing module lookup. I mentioned using it internally and someone much smarter than I seemed hesitant at the idea without elaborating much on why in discussion. So, just wanted to double check on best practices.
You’re welcome! Someone much smarter than me may come by and say I’ve got it wrong 
But I think you can point to a lot of cases in plain Elixir where we can pass in an MFA arg, e.g. all of the Task functions that take an MFA, and even the the :start option in every child spec takes an MFA (__MODULE__, :start_link, [args]), so somewhere behind the scenes there must be an apply call to make that work
Just because…
You could create an apply macro.
defmodule Foo do
defmacro apply(module, function, args) do
quote do
unquote(module).unquote(function)(unquote_splicing(args))
end
end
end
require Foo
Foo.apply(IO, :puts, ["hello"])
Foo.apply(Enum, :sum, [[1, 2, 3]])
apply is not bad, but I think it is possible to avoid it in almost 90% of use cases.
First of all, try to use Elixir’s protocols, they’re more efficient and can be verified with dialyzer.
Second, you can specify behaviour and then use something like
module = MyModule
module.function(arg)
Because this can also provide some information for dialyzer.
Then, I’d try to use closures via fn, because they can be typed and be used with dialyzer.
And only if all suggestions above are not applicable, I’d use apply/3
Would it be possible to have the module variable (an atom) directly instead of module_name as a string ? For instance by writing (or generating) lookup functions like this:
defp lookup("my_mod"), do: MyApp.MyMod
defp lookup("other_mod"), do: MyApp.OtherMod
So you can just call lookup(module_name).some_func(arg0, arg1) if the length of the arguments list is always the same, or apply(module, :some_funct, args)
Also note that by calling apply(String.to_existing_atom("Elixir.MyApp.#{module_name}", :some_func, [args])) you are passing a single argument, args, since you put that variable in a list itself, whereas the variable name tends to tell that it is already the list of arguments.
yeah i suppose it could be done that way. are you suggesting this is better practice than using apply? my reasoning for wanting to use apply as above is to avoid having to maintain a file of lookup clauses.
If the only thing that is dynamic is the module name, you can just do:
some_module = build_me_my_fancy_module()
some_module.some_func(arg)
For instance:
defmodule Foo do
def prepend_myapp(module), do: Module.concat(MyApp, module)
end
defmodule MyApp.Bar do
def hello(name), do: IO.puts("Hello, #{name}!")
end
iex> Foo.prepend_myapp(Bar).hello("Cherry")
Hello, Cherry!
To add on this:
ModuleName.myfun(arg1, arg2, arg3)
module_in_a_variable.myfun(arg1, arg2, arg3)
Function.capture(MyModule, function_name_in_a_variable, 3).(arg1, arg2, arg3)
Function.capture.apply.cool, yeah i also like this idea.
Here’s a wrapper function called maybe_apply which we use to call functions in modules that may or may not be present in the current app (or even disabled in config), in which case a fallback function is called (which by default is just for error handling): bonfire_common/utils.ex at main · bonfire-networks/bonfire_common · GitHub
Feedback appreciated, as I’m sure it can be improved!
PS: you’re also able to pass a list of function names, and the first match that exists will be applied.
© Copyright Elixir Forum | Terms | Privacy & Cookies
