[erlang-questions] Parameterized module initialization

[Loïc Hoguin]

On 06/28/2012 11:03 AM, Joe Armstrong wrote:
> On Thu, Jun 28, 2012 at 1:24 AM, Robert Virding
> <robert.virding@REDACTED> wrote:
>> I quite agree. Having finally got rid of {M,F} please,please,please don't replace it with something even worse. I am no great fan of parametrised modules but if they are to be properly added to the language then do it as an opaque data type and use the module:new function to initialise it.
>
> But it's not worse. The "sneaky" mechanism has the additional advantages over
> paramterised module:
>
>     1) Variables in the body of a function "appear by magic" - ie they are not
>          declared in the head of the function. So I can't just cut and
> paste code from
>          one module to another.
>     2) You can only have one "new" constructor (I am correct here)
>          suppose I have one group of function in a module that need access to
>          module parameter variables A,B,C and some other set of functions needs
>         different variables P,Q,R - If I understand correctly this can't be done
>         (this should be solved by a letrec, but that's a different discussion)
>      3) This provides a very convenient syntax for the user of a module
>           X:some_function(...) is very familiar to users of other programming
>          languages (like Javascript) - the idea that X contains some state is
>          "normal" for most programmers coming to Erlang from other languages

Sure, these people are used to X:some_function(...). But are they used 
to X2 = X:some_function(...)? When they do X:some_function(...) they 
then do something similar to $this->value = 'blabla' and expect X to be 
changed magically. So the comparison falls short.

The problem with doing what you do is two-folds.

First, you make things happen implicitly. It's not obvious what happens 
exactly unless you know the language. some_function(..., X) is obvious 
to almost all programmers, X:some_function(...) isn't for the reasons 
stated above: you can't modify X and expect X to change. I think being 
explicit helps a lot more readability.

Second, you actually make things more confusing. See this small snippet:

X = {utf8_string, 1, 2, 3},
X:some_function() %% this calls utf8_string:some_function/1

Y = utf8_string,
Y:some_function() %% this calls utf8_string:some_function/0

This means that you need to know what's in your variable to know the 
function that will be called. It's fine if your application is small and 
you know every bits of it. But for bigger systems where these variables 
might be set in different applications or different nodes, you never 
know what you'll get. This makes things incredibly hard to read and debug.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines