vrod
First time Elixir macro -- generate similar functions?
This is my first time I am looking at macros. I think I understand they are something like “pre generation” of code. Maybe something like using PHP templates to make Javascript code – they make Elixir code before it runs? OK this is maybe a bad example.
What I am trying to do is this: I have multiple functions that are almost all the same. Each one gets a thing from an API. Each one is the same, but each one returns a different struct. All of them look like this:
defmodule Thing1Resolver do
def get_one(args) do
data = get_from_api(args)
struct(Thing1, args)
end
end
The only difference is the module Thing1 is different for each function (Thing2, Thing3, Thing4). Can I write a macro to use and build functions like this? So maybe my resolver modules look like
defmodule Thing1Resolver do
use Shared, struct: Thing1
end
Is this possible? Maybe it is a bad idea. I want to understand how it works and then I can decide.
Thankyou
Most Liked
al2o3cr
You could use macros for this, but since it’s really just substituting a value for thing it’s not a great fit.
Macros are really powerful when you want a piece of code to generate multiple related functions / data, or code that depends on the whole module’s settings. For instance, the Ecto.Schema.schema macro generates __changeset__ and __schema__ functions after all the schema fields are defined along with setting many module attributes.
al2o3cr
Because this:
defmodule FooBar.Thing1Resolver do
use FooBar.Share, struct: FooBar.Thing1
import FooBar.Creator
defcreate(FooBar.Thing1)
end
is harder to read than this:
defmodule FooBar.Thing1Resolver do
def new(args) do
struct(FooBar.Thing1), args)
end
def create(args) do
struct(FooBar.Thing1), args)
end
end
For instance, it’s considerably less obvious the functions generated in Thing1Resolver in the first version are identical since their definitions are split among two modules and use arguments differently.
Another approach to consider: put as little code in the macro as possible and call out to the real implementation. This is part of what happens when you say use Ecto.Repo in your application:
defmodule FooBar.Share do
defmacro __using__(opts) do
struct_name = opts[:struct]
quote do
def new(args) do
FooBar.Share.new(unquote(struct_name), args)
end
end
end
def new(struct_name, args) do
struct(struct_name, args)
end
end
defmodule Wat do
use FooBar.Share, struct: Wat
defstruct [:val]
end
Wat.new(val: 1)
Here the macro generates a function which adds in the argument passed to use but delegates all the functionality to a function defined on FooBar.Share. There’s a tiny compilation space/performance improvement since less AST is generated, and there’s less thinking about tricky things with unquote.
John-Goff
Why not just have a function that takes the type of struct? Something like
def get_generic(thing, args) do
data = get_from_api(args)
struct(thing, args)
end
Also note with this code you’re not using the API result for anything, and it’s essentially doing nothing, assuming there are no side effects from that API call.








