Will parameterized modules become an official part of Erlang?

[Tim Fletcher]

> The reason is that we need to supply a call-back module implementing a
> behaviour to a generic module like gen_server or gen_fsm, and the callback
> module needs access to parameters that aren't fixed. So we use a
> parameterised call-back module and pass that to the generic one. This is the
> same kind of example that motivated Richard Carlsson's paper in the first
> place... and there isn't any other good way of solving the problem. Making
> the parameterised module into a gen_server instead, which has been
> suggested, isn't a good solution in this case because it's not
> reentrant--you can then only have one "instance" of the parameterised module
> at a time. What if you need more?

I'm not sure I fully understand all of this, but couldn't you just
spawn more servers/processes?

If the gen_server callback interface was specified in terms of
messages instead of function calls, then all it would depend on is a
process that implements that message interface. You could either use a
single callback process with several servers, or one process for each
server. You could even chain together several processes to extend/wrap
existing behaviour.

Taking the example from Richard's paper, module A would call module C
to start a new callback process, and then pass that reference to
module B to configure the callback behaviour.

I'm probably being naive about concurrency issues... what am i
missing?


Tim