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?
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…
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.
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 use
ing 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.