[erlang-questions] (Non)Parametrized modules, inheritance, and R15B02 issues?

[Dmitry Belyaev]

My opinion is that parametrized modules are very nice for abstractions.

For example like these:
https://github.com/rabbitmq/erlando#monad-transformers

Of course it is doable without pmods. But it is doable with some kind of reinventing the wheel. Do we need to have non standard way to do the same thing?

-module(my_pmod).
-export([new/2, apply/2]).
-record(my_pmod, {module, thid}).

new(Module, Params) ->
	#my_pmod{module=Module, this=Params}.

apply(#my_pmod{module=Module, this=This}, Fun, Params) ->
	apply(Module, Fun, Params ++ [This]).

-- 
Dmitry Belyaev


On 10.10.2012, at 11:10, Ulf Wiger wrote:

> What would be good is if a list of good uses of pmods could
> be collected, and honorable workarounds suggested.
> 
> This could of course be done interactively on this list.
> Present what you think is code that is not easily done well
> without pmods, and let the members of this list debate
> suitable rewrites. If good alternatives are hard to find, 
> maybe that could inform some EEP for a more
> 'erlangish' extension that renders pmods truly obsolete?
> 
> BR,
> Ulf W
> 
> 
> On 10 okt 2012, at 00:54, Tomas Morstein <tmr@REDACTED> wrote:
> 
>>>> ...
>> 
>> The problem starts when it comes to projects like ChicagoBoss
>> that we at IDEA love and intensively use every day.
>> CB uses pmods not only for simple_bridge-based web controllers,
>> but also for its sophisticated and well integrated concept of
>> data models being linked with Django templating engine in turn.
>> 
>> Although I fully understand reasons why pmods and their eventual
>> pseudo-OOP behaviour (like inheritance) are not so clear as they
>> are implemented today, but in other hand, many excellent projects
>> may disappear in final result...
>> 
>> I hope such a "total eclipse" is not going to happen, but our case
>> (over-using the extra unsupported and hackish features) we've just
>> adapted our technology to framework and totally forgot to standards,
>> what's in fact our own mistake.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions