Parameterised modules

Mikael Pettersson mikpe@REDACTED
Mon Sep 1 15:46:58 CEST 2003

Sean Hinde writes:
 > Hi,
 > A few thoughts on the proposal for parameterised modules as presented 
 > at the Erlang Workshop on Friday.
 > The two main examples given are nice enough in themselves, but 
 > comparison with real world apps points out a couple of problems.
 > The first example is of a generic server, where the server module can 
 > be parameterised with the name of the callback module and a process 
 > registered name:
 > Server = server:new(Name, Mod).
 > If we look at gen_server however there are two startup functions - one 
 > with 3 parameters and one with 4 - one which provides a registered name 
 > and one which doesn't. It is not clear to me that a parameterised 
 > gen_server could offer both variants (given a fixed number of 
 > parameters in the module definition), withought imposing on the user 
 > some convention that if the registered name was say '$undefined' then 
 > the register step would be explicitly skipped.

Either using a convention with an out-of-band value denoting "don't"
or adding a second boolean DoReg parameter will work. (But see below.)

 > The second example is of providing a user defined log function at 
 > module instantiation. Every time I have wanted to provide for a user 
 > definable log function I have also wanted to have a built in default 
 > logger, and provide the caller the option to provide their own if 
 > desired. I do not see any way to provide a default value for a 
 > parameter in the proposal for parameterised modules.

1. Whoever does the instantiation gets to choose. This works
   perfectly in Standard ML, whose parametrized module system
   was the original inspiration for HiPE's work on the same.

2. Something like

   -module(foo, [{Label,Default},...])

   and change foo:new() calls to pass the values by Label

   foo:new([{'Log', sean_logger}])

   and any omitted Label would get its default value.

   This would be a fairly simple change I think.

   This could also solve your maybe-register problem. Omitting the
   RegisteredName parameter lets it take on a default value, whose
   encoding is private to the module. Clean, no?


More information about the erlang-questions mailing list