[erlang-questions] Advice on meta programming problem

[Garrett Smith]

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