I just want to quickly note that one of the goals of Absinthe 1.5 is to need less macros to dynamically define a schema, and I know other people are working on making it simpler as well.
axelson
Scenic Core Team
Eiji
The problem is that people don’t want to write absinthe schema with absinthe macro, but dynamically generate absinthe schema based on ecto database representation + some extra checks and rules.
0
cjbottaro
Oh… well now we’re going to get into a difference of opinions.
so you can do:
defmodule Document.InputObjects.Schema do
# …
defp filter_name({:__aliases__, [alias: false], list}) do
list
|> List.delete("Schema")
|> Enum.join()
|> Macro.underscore()
|> append("_filter")
|> String.to_atom()
end
defp append(string, suffix), do: string <> suffix
# …
end
Just because we can do something doesn’t mean we should… or in this case, it’s simpler and/or more readable to eval the args before passing them, instead of passing AST tuples. Also, the arguments are not coming from “user input” so there is no concern with eval’ing them.
I feel like there are two approaches to Elixir metaprogramming:
- We’re going to help you and hold your hand (and here are the module/funcs to do so)
- Eff it, here’s the AST and do as you please before sending to the interpreter to execute
So I see what you’re saying: everything can be done at an extremely low level. But if I can do stuff at a higher level, that’s supported by the language’s standard lib. Shouldn’t I do that before just mucking with ASTs?
0
Eiji
Firstly AST is not extremely low level if we are talking about Elixir. 
Well … I have one really good example from my experience …
My first job … I have worked with Ruby/Rails. I saw really small monkey patching usage from someone who was more experienced than me. I liked how it’s simple (so there was no need to change existing code) and I have stupidly changed file with just few lines of monkey patching into weird file with hundreds of lines with monkey patching.
If something is supported it does not mean that it should be always used. Especially when we are talking about evals. Look … I believe that Joomla! and Wordpress developers are not stupid. Same goes to developers of (at least most popular) extensions for those projects. The problem is that lots of sites was trivially hacked by adding PHP code into image files - just because they used eval.
Sure, one module looks safe, but can you guarantee that this will be still safe after few rotations in dev team? Can you guarantee that it will be still safe after somebody in team decides to move such generator (with eval call) to open source library? Software is changing really rapidly.
If we are going always with easiest solution then we will end with something like Windows in few weeks/months. Windows was created by definitely good developers, but looking how it changes in years we see that something is definitely wrong. For example compare modern (with rewritten code) Plasma 5 features and requirements with what offers Windows’s builtin window manager. I can’t do even as good job as that made in both projects, but still I (being not experienced in OS programming) see huge differences.
Also my solution is not about only “low level”. We have here typical pattern matching which prevents to add data of any type. We can always add simple guard to check if module have Schema part in list too without bigger problem.
Summary:
- It’s safe - no matter who will use it and no matter if you made mistake
- It’s at least as simple as with eval (in implementation)
- It’s definitely faster solution
Therefore I’m not sure what’s wrong with my hint.
0