[erlang-questions] Advice on meta programming problem

[André Graf]

Can't you use something similar to the mochiglobals module for that? I
know people at Basho use it within their Lager logging framework for
managing different log levels. I used a similar approach for enabling
and disabling a mocked port driver.

PS: Garrett.. missed the "reply to all" button



On 19 May 2012 15:57, Lukas Larsson <garazdawi@REDACTED> wrote:
> 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 <g@REDACTED> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions