My main concern is to introduce another mechanism where functions are dynamically added to modules. The issue with __using__ is that it is too generic but that it is also its blessing as we have a single entry point.
It is also worth saying that we should generally stop defining default implementations. We should use @optional_callbacks and function_exported? if the callback is truly optional. That's the direction we are moving GenServer, Supervisor and friends. See previous discussion here: https://elixirforum.com/t/behaviours-defoverridable-and-implementations/3338 *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D* On Thu, Nov 16, 2017 at 2:25 PM, Christopher Keele <[email protected]> wrote: > I find that it is rather rare to provide default callback implementations >> for most behaviors >> > > To be fair, I have been working on a project on and off for over a year, > that contains two very large behaviours, where all callbacks are mandatory, > but a majority of them can offer a default implementation derived from a > few core ones—but should be overridable for performance optimizations. In > short, the worst case scenario for the current common pattern; I'm sure > this has exacerbated my frustration beyond normal levels. > > You could also place default implementations in the behavior module >> itself and use defdelegate from the __using__ macro > > > This is the approach I was using for a while. The code in the gist I've > linked to is essentially defining such a __using__ macro for you, for all > of your callback functions, using a handrolled version of defdelgate that > can also preserve documentation and optionally inline, instead of just > delegating, the default implementations. Again, traits necessary to my > usecase but ones that I think would nice to have in a boilerplate macro. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/309216d9-81fb-4a83-9a8e- > c7034d00d6ce%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/309216d9-81fb-4a83-9a8e-c7034d00d6ce%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JQEK0tASFbuo%3Dq0y0i7ZMwdt0CAt3TbK%2Bw0Cikpie4zQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
