Oliver
Macro does not like module attribute?
In file 1:
defmodule Utils.Struct do
# this is for importing definitions when "use Utils.Struct" is called
defmacro __using__(_opts) do
quote do
import Utils.Struct
end
end
defmacro defstruct_module(struct_name, fields) do
quote do
defmodule unquote(struct_name) do
use Utils.Access
defstruct unquote(fields)
end
end
end
end
In file 2:
defmodule Statistical.Generator do
use Utils.Struct
@in_files [:in_cause, :out_cause, :start]
defstruct_module(State, @in_files)
Breaks:
warning: undefined module attribute @in_files, please remove access to @in_files or explicitly set it before access
<some file>: Statistical.Generator.State (module)
== Compilation error in file <some file> ==
** (ArgumentError) struct fields definition must be list, got: nil
(elixir 1.14.4) lib/kernel/utils.ex:117: Kernel.Utils.defstruct/3
But this works - again file 2:
defmodule Statistical.Generator do
use Utils.Struct
@in_files [:in_cause, :out_cause, :start]
in_files = @in_files
defstruct_module(State, in_files)
By the way, if I use the variable approach instead of the module attribute, than the def blocks of the module in file 2 complain… can’t win? ![]()
Is this because the it inserts the module attribute verbatim as abstract syntax tree? Is there a construct/pattern to handle this case - like would a bind_quote help?
Thank you!
First Post!
DaAnalyst
To use the module attributes in your macro, you’ll need to do it in __before_compile__/1.
Take a look at this upgrade of my library which was done precisely for the same reason
(see the difference between v0.2.0 and v0.1.0) - kudos and thanks to @kip
Most Liked
josevalim
Correct. You could instead first unquote it in its actual scope:
quote do
fields = unquote(fields)
defmodule unquote(struct_name) do
use Utils.Access
defstruct fields
end
end
Last Post!
DaAnalyst
If you look at my lib code, you’ll see that in its first version (0.1.0) it simply relied on the vanilla macros to expand the def assign_* and friends. The problem with that approach was that it could only take a list of atoms and not a module attribute (to which a list of atoms is assigned) because the module attribute was not resolvable at the time of the macro expansion. The __before_compile__/1 approach that was suggested by @kip solved this (as shown in the version 0.2.0) because at the time it expands it can resolve the module attributes, hence the necessary refactoring.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









