[erlang-questions] Advice on meta programming problem

Lukas Larsson <>
Sat May 19 15:57:40 CEST 2012


If you are ok with using a "factory" to create a param module, you
could just as well use it to create a first argument to pass to the
function. i.e.

-module(foo).

create_context() ->
  application:get_env(myapp,registered_foo).

do_something(Context) ->
  Context:do_something().

unless of course you have a reason for not wanting the parameter to be
explicitly passed?

Lukas

On Sat, May 19, 2012 at 12:02 AM, Garrett Smith <> wrote:
> 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
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list