Function overriding at compile time

If it’s for logging calls or computing statistics, you could use the standard tracing tools in Erlang’s dbg module.

Either you use the on definition callback to collect data which you apply in before compile, or you require your client to annotate each function explicitly either by listing them as argument to your useing or as in the decorator package.

There were a lot of discussions about decorators and only a handful of people actually wanted them, most said they are not necessary…

So the few that needed them created the package and still seem to maintain it.

Yes my client would have to call use.

Unlike other hooks, @on_definition will only invoke functions and never macros. This is to avoid @on_definition callbacks from redefining functions that have just been defined in favor of more explicit approaches.

I’m not sure if it apply to simple approach you guys suggested or just for dude who would like to insert code in a function. That’s why i didn’t dig deeper in this way

Your client has to be explicit somewhere about what you shall change.

Either he has to call explicitly your service per function, or he has to use moduleattributes to annotate the functions as in :decorator-package, or he has to tell when useing your module.

You should be able to use that information the client provided in a @on_defintion callback.

Thanks for the package, I did find some, but not this one.

On_definition, I understand prevent(or try to) redefining the actual function.

I try to have

defmodule A do
   use MyPlugin
   def foo, do: ...
 end

and under the hood it would compile like

 defmodule A do
   def foo, do:stuff1
   def foo, do:stuff2and stuff1
 end

The thing is, I’m not naming the function foo but the client of the module is. And me I’m just providing him a plugin.

A callback is implemented against a contract given by a behaviour, which dictates names and arities, so you now all you need…

Please check if the :decorator package suites your needs or if you can take some insights from it.

Maybe you can also pull some use from the @on_definition module attribute.

At the moment, I really can’t tell you anything more, since I simply do ot understand what you want to achieve… You say, you want to decorate all foo, but then you say you do not know what you want to decorate, and then again you say thats a callback, so you have a contract… I’m confused about your plans…

The log was just an example. Its just some callbacks

You neither know how the function will be named nor what arguments it might get? What do you actually want to log then?

Or better probably this

def foo(x, y, z) do
  log_stuff(...)
  do_foo(x, y, z)
end

defp do_foo(...)...

This way only the decorator is accessible and doesn’t have an obfuscated name.

I’m not supposed to write anything in the module A. So a client would go:

 defmodule A do
   def foo, do: ...
 end

and under the hood it would compile like

 defmodule A do
   def foo, do:stuff1
   def foo, do:stuff2and stuff1
 end

And my main problem is that i don’t know the name and arity of foo function. So it’s acutally hard to have any simple strategy like @kokolegorille suggested.