[erlang-questions] Process Dictionary vs Proplist in Web Frameworks

[Jayson Vantuyl]

I'd say no, for a few reasons.

1.  It makes it difficult if you ever do need to split stuff up into  
multiple processes.  As soon as you need a "helper" process, all of  
your data is inaccessible.
2.  It makes it difficult to debug via tracing.  You can trace  
function calls, tracing changes to the process dictionary is a bit  
more hairy.
3.  If you want to "hide" the proplist, just pass around some sort of  
"request" record.  Then you don't see it unless you access the  
record.  Or use macros and message a "request" process for the data.
4.  If you use Mnesia, transactions can be retried, so you may end up  
with your mutations happening multiple times if anything happens  
inside of a transaction.

I don't deny that Erlang needs some better syntax and conventions for  
passing data around (preferably via namespace magic like Ruby or  
Python), but the process dictionary can break a quite a few  
assumptions and break quite a few useful patterns.  This could be fine  
if you're the only one writing the code, but you the process  
dictionary, in the wrong hands, can make many an Erlanger curse your  
name.

On Oct 28, 2009, at 6:46 AM, Ngoc Dao wrote:

> Hi,
>
> Web frameworks are normally designed as layers (web server ->
> middleware -> front controller -> controller -> action -> view ->
> etc.). Data needs to be passed from one layer to another. There are 2
> ways to pass:
> 1. Proplist (environment variables)
> 2. Process dictionary
>
> The 2nd way:
> * Is Simple and natural in Erlang because normally one HTTP request is
> processed by one process.
> * Makes application code which uses the framework appear to be clean,
> because application developer does not have to manually pass an ugly
> proplist arround and arround.
>
> I want to ask about the (memory, CPU etc.) overhead of process
> dictionary, compared to proplist. Which way should be used in a web
> framework?
>
> Thanks.
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>



-- 
Jayson Vantuyl
kagato@REDACTED