Very nice ! just sent you a couple of PR for your new project. 
vic
Asdf Core Team
arjan
michalmuskala
I will second @benwilson512 here - I’m not sure decorator pattern really fits in Elixir.
As to instrumentation - we have the awesome tracing abilities that allow us to introspect function calls without adding any line of code - even in production.
There are native things in :dbg and :trace, but I prefer :recon and recently started using GitHub - tatsuya6502/recon_ex: Elixir wrapper for Recon, tools to diagnose Erlang VM safely in production · GitHub
# Prints next 3 calls to SomeModule.function with return value
ReconTrace.calls({SomeModule, :function, fn _ -> :return end}, 3)
# Prints next 3 calls to SomeModule.function with return value in process pid
ReconTrace.calls({SomeModule, :function, fn _ -> :return end}, 3, pid: pid)
It’s much more powerful, than this. Those should be good examples of things I use the most.
2
slashdotdash
Just discovered your decorator library as I was searching for exactly this behaviour. Wrapping method calls with timing traces. Perfect solution for me; thanks for making it available.
1
josevalim
Creator of Elixir
This may be too late but you really really really shouldn’t copy Elixir’s private source. When you rely on Elixir internal details and then your code breaks when users of your code update their Elixir version, it gives a sense of instability to the ecosystem while we are working very hard to keep Elixir backwards compatible.
One suggestion is, when you are traversing the AST, you should see if that’s a decorated attribute and, if not, you should regenerate it as Kernel.@(ast) or something similar.
However, you should not need to traverse the AST to implement decorators. It should be possible to implement this by using @on_definition. Since @on_definition is going to be invoked before every function clause, you can collect information such as function body, arguments, etc and then use @before_compile to traverse all of the collected functions, calling the decorator, and emitting new clauses. You can also use defoverridable and tell decorators to simply invoke super when they need to call the parent function.
Here is an example implementation:
defmodule Decorator do
defmacro __using__(_) do
quote do
@on_definition Decorator
@before_compile Decorator
@decorators %{}
@decorator nil
end
end
def __on_definition__(env, kind, fun, args, _guards, _body) do
if decorator = Module.get_attribute(env.module, :decorator) do
decorators = Module.get_attribute(env.module, :decorators)
decorators = Map.put(decorators, {kind, fun, length(args)}, decorator)
Module.put_attribute(env.module, :decorators, decorators)
Module.put_attribute(env.module, :decorator, nil)
end
:ok
end
defmacro __before_compile__(env) do
decorators = Module.get_attribute(env.module, :decorators)
for {{kind, fun, arity}, decorator} <- decorators do
args = generate_args(arity)
body = decorator.decorate(kind, fun, args)
quote do
defoverridable [{unquote(fun), unquote(arity)}]
Kernel.unquote(kind)(unquote(fun)(unquote_splicing(args))) do
unquote(body)
end
end
end
end
defp generate_args(0), do: []
defp generate_args(n), do: for(i <- 1..n, do: Macro.var(:"var#{i}", __MODULE__))
end
defmodule InspectDecorator do
def decorate(_kind, _name, args) do
quote do
IO.inspect super(unquote_splicing(args))
end
end
end
defmodule Sample do
use Decorator
@decorator InspectDecorator
def add(a, b) do
a + b
end
end
# Should print 3
Sample.add(1, 2)
I don’t quite agree with the idea but I believe the implementation above would be better than relying on Elixir internals. The sketch above is also not complete, for example, we don’t support multiple decorators, but you should be able to change it by changing the on_definition implementation.
18
arjan
Thanks José for your reply. At the time, overriding Kernel.@ felt like the only solution, but I’ll revisit this based on your example. Your solution looks elegant – I never knew you could override a function from within the same module.
I’m still wondering how to do multiple decorators without inspecting the module’s AST or doing something with Kernel.@ though, because the putting 2 @decorate module attributes below each other just causes the last one to overwrite he previous value iirc.
0
vic
Asdf Core Team
They wont if you define the attribute like Module.register_attribute __MODULE__, :decorate, accumulate: true, then it will be a list (latest attr value would be first), and you can just get this list __on_definition__ and reset it to nil for next functions.
3
arjan
slashdotdash
Here’s the usage of the decorator I implemented.
defmodule ProgressDecorator do
use Decorator.Define, [progress: 0]
def progress(body, context) do
quote do
reply = unquote(body)
case reply do
list when is_list(list) -> Progress.incr(unquote(context.name), length(list))
_ -> Progress.incr(unquote(context.name), 1)
end
reply
end
end
end
It’s used to track progress of the stages in a Flow pipeline to generate a visualisation.
2
arjan
I’m getting there but there’s one issue with this approach, and that’s when decorating a private function, Elixir raises a warning that defoverridable is deprecated for defp’s. Any suggestion on how to address this?
I guess the easiest way is to stop supporting decorators for defp altogether
0