[erlang-questions] Re: Will parameterized modules become an official part of Erlang?

[Garrett Smith]

On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
> Garrett Smith writes:
>  > > We still have time to ditch them :)
>  >
>  > +1
>  >
>  > I think the concept is fine, but if they take off they're going to
>  > bifurcate Erlang APIs into traditional API modules that take explicit
>  > process refs/state and this other breed that somehow gets by without
>  > them. Yuck!
>  >
>  > IMO, this meme (coupling state and behavior) is way too fundamental to
>  > have two major variants in a language.
>
> The parameters in parametrized modules are no more about state than
> the free variables in function closures ('fun' expressions) are.
>

Okay.

Throw in the fact that you can call functions on a module that have
access to these arguments and you have a coupling between these
argument values and functionality. Sorry if "state" wasn't pedantic
enough for you.

My point is that this pattern is handled adequately without needing
parameterized modules and to have two approaches for something this
fundamental in a language is bad. I've observed practiced Erlang
developers look sideways at mochiweb's Req:respond(...), look confused
for a moment, and then conclude that it must be this unofficial
feature called parameterized modules. What's the point of this? It's
not unlike stumbling on the use of the process dictionary: "ah,
*that's* how they're doing it!" IMO, this should be avoided wherever
possible - and it's very avoidable in the case of parameterized
modules.

(Btw, I'm not even remotely slamming mochiweb here. It just happens to
be the premiere example of this feature.)

Garrett