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

[Tamas Nagy]

Hi Attila,

Well if you would like to see the gen_server's state you can always do  
a sys:get_status/1.

Regards,
	Tamas

Tamas Nagy
Erlang Training & Consulting
http://www.erlang-consulting.com

On 1 Nov 2009, at 12:13, Attila Rajmund Nohl wrote:

> 2009/10/29, Geoff Cant <nem@REDACTED>:
>> [...] Erlang programmers
>> usually only have to think about the function body and arguments to  
>> work
>> out what its going to do. Sprinkling 'get' and 'put' through the code
>> means that an erlang programmer trying to understand your code now  
>> has
>> to read all the code to figure out why something is happening. The  
>> order
>> in which functions are called becomes important. The behaviour of
>> functions in other modules becomes important because now there's a
>> back-channel to propagate bugs, er, state between parts of the code.
>
> This is not related to the process dictionary. If the programmer
> implements e.g. a handle_call in gen_server 'A' (or anything that's
> called from that handle_call), he has to make sure that he doesn't
> call gen_server 'B' if there's a chance that 'B' called 'A' first -
> otherwise there would be a deadlock. In this case also a lot of other
> code gets important and it's fairly common that a handle_call (or a
> function called from handle_call) gets implemented...
>
> Like it or not, it's important that in what circumstances a function
> is called - this is a limitation in Erlang's "functional
> languageness", but actually this is necessary to do anything useful
> with the language.
>
> The process dictionary could be great for environment-like variables,
> which are only set once, but used in very many places and it's very
> inconvenient to pass around one more parameter. They don't show up in
> function traces - but they do show up in the output of
> erlang:process_info(), where e.g. the gen_server state is not shown,
> even though it would be dead useful.
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>