Function overriding at compile time

Is there any way to, at compile time overrid ALL functions foo that somebody would wrote in a module A.

I think I can do it overriding def/2. But I feel like i would be using a hammer. Any ideas?

What do you mean by overload?

Using super. Sorry isn’t overload the word? Overrid is probably closer to what i think

Using super is the OO way to call parent object. That is not really working like this because there is no object in Elixir, just modules, functions and arguments. Composition is also preferred over inheritance… composition everywhere

@kokolegorille but if I have a funtion foo and juste want to overrid it, to print some log. Should i use something else than Kernel.super ?

You have to call super explicitly.

But it seems as if you want to use something known as decorators. I’ve seen an experimental package for those years ago, not sure if it still works or is maintained.

At least I remember it had problems with multi headed functions.

The easiest is probably to simply call the logger explicitly at the places you need it…

1 Like

Maybe like this

def foo, do: ...

def foo_with_log do
  log_here
  foo()
end

I know it’s not override like You want… but You can easily compose functions.

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.

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.

1 Like

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

The log was just an example. Its just some callbacks

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…

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.

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.

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

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.

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