[erlang-questions] about the use of parametrized modules

[Roberto Ostinelli]

i can only reply afa my personal experience is concerned.

1. there are certain variables that are totally useless to a developer
using misultin, such as SocketPid in a request [1]. this is an
internal variable used to provide streaming functionalities, which
provides absolutely no added value to a developer. on the contrary, it
could generate issues if misused.

2. a request, and all of its 'properties', is by concept very similar
to an 'object' even though it still is a module underneath, in the
same way 'records' actually are similar to 'named lists' and are lists
'in disguise'. it's just a matter of 'grouping' some small
functionalities alltogether in the name of this same 'object'. point
here is that the module functionalities are *all* so dependent on
*the* very same variable [Req], that a module actually gets 'attached'
to the variable itself.

therefore, it's very simple: i've used parametrized modules in
misultin because of a simple matter: _code useability_.

for instance, in misultin the code to send out a file as an attachment
is as follows:

% callback on request received
handle_http(Req) ->
    Req:file(attachment, "/usr/local/files/image1.png").

if i weren't using parametrized modules, it would look something similar to:

% callback on request received
handle_http(Req, SocketPid) ->
    Req:file(Req, SocketPid, attachment, "/usr/local/files/image1.png").

true, you would know that, in order for this to work, you need to pass
both Req and a variable called SocketPid. but you wouldn't have the
slightest clue on why the latter it's there, nor what can you do with
it. i don't see any value added in making these variables explicit to
the developer, instead of having them 'masked' by the use of
parametrized modules.

i do realize this can sound like a blasphemy to erlang purists, and
that this can lead to incongruence in approaching code. as always,
it's a matter of tradeoffs, and taste. my evaluation was that i by far
preferred easing code readability of applications based on misultin. i
haven't seen [i might be corrected, though] anywhere written that
these parametrized modules present particular running issues when
compared to 'explicit' code.

just my 2 cents, apparently not popular ones since everybody seem to
dislike parametrized modules :)

r.

[1] https://github.com/ostinelli/misultin/blob/master/src/misultin_req.erl