[erlang-questions] about the use of parametrized modules

[Hynek Vychodil]

On Fri, Jan 14, 2011 at 5:07 PM, Roberto Ostinelli <roberto@REDACTED> wrote:
> 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").

What prevent you add SockedPid to Req and above code would look like?

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

Which is not so much different from

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

It already contain socket and socket_mode, why not SockedPid?

Problem with your code is, when I read

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

and I want to see implementation of function file. Where I should
look? I have to know *out of band* information that I should look to
misultin_req module. I have to look for. I have to find. Why the hell
is code encrypted? It same applies to mochiweb. I have to spend
nontrivial time find out the module of implementation every time
someone use parametrized module. It hurts. It hurts users of your code
absolutely uselessly.

>
> 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
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill
your boss.  Be a data hero!
Try GoodData now for free: www.gooddata.com