[erlang-questions] Parameterized module initialization
Wed Jun 27 18:08:13 CEST 2012
On 06/27/2012 06:01 PM, Tim Watson wrote:
> Yes, wouldn't existing stuff like xref and dialyzer and cover and so
> on, require less patching this way also?
> On 27 Jun 2012, at 10:18, Anthony Ramine<n.oxyde@REDACTED> wrote:
>> I find it way saner for a parameterized module to be a mapping from
>> modules to modules than to be a way to encapsulate some arbitrary
>> I may be wrong but I think that it would be easier to implement and
>> reason about them in a non leaky way if their arguments were only
>> module names.
In a statically typed language like ML, restricting the type of
structure parameters to also be structures makes sense. It means that
the functor is something that takes one or more smaller structures
implementing some specific interfaces (classic examples are generic data
types like a queue), and returns a new, larger structure that builds on
the given structures. As far as I know, functor instantiation is done at
compile time only, but using separate compilation for each involved
structure. This basically means that instantiating a structure by
another structure can be done by patching code pointers (and nobody
needs to pass around an object/vtable). Since the signatures have been
checked, nothing can "go wrong". Allowing other data types than
structures as parameters would make separate compilation difficult
(compare C++ templates). But it also means that the only way to
parameterize a structure over a constant - say, the gravitational
constant for a simulation - is to create a separate GravityConstant
interface with a single function that returns the value to be used.
That's a bit more boilerplate than I would like.
In Erlang, however, there is no reason to limit the type of a module
parameter. Indeed, the only way to enforce it would be to add runtime
checks at each entry point. The implementation is not simplified - it
gets more complicated. In practice, it is probably a good idea to mostly
parameterize modules with respect to other modules (i.e., callbacks),
but there's no point in trying to enforce that.
More information about the erlang-questions