I want to register a module that implements a callback interface. I
don't want to use Erlang processes for this case -- otherwise a custom
OTP behavior would suffice
I want to use the module through an abstract layer like this:
foo:do_something()
I want to register a particular implementation of "foo" in application
config like this:
[{my_app, [{registered_foo, my_foo}]}].
my_foo would export do_something/0, which would be called by foo:do_someting/0.
There are no registered processes here.
I know I can use parameterized modules:
-module(foo, [M]).
-export([do_something/0]).
do_something() -> M:do_something().
So easy!
This does require some "factory" support to setup the parameterized
module from application config. Not a big deal though, at all.
Then there's my irrational, emotional hang-up of using parameterized
modules, which is a more serious problem.
I'm tempted to assemble a module at runtime using the standard
metadata conventions in Erlang (code, compile etc. modules).
foo would look like this:
-module(foo).
-export([do_something/0]).
do_something() -> foo_impl:do_something().
foo_impl would not exist at compile time -- it would be generated at
runtime using the application config.
This is a very simple example -- more complex scenarios could exist,
such as multiple implementation modules providing functionality.
I'm curious to hear general reactions on this. Obviously parameterized
modules fit -- but I'd like to explore some other approaches as well.
Garrett