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

[Ngoc Dao]

Max,

I agree that using PD arbitrarily is bad. But using PD restrictively
is controllable.

A web processing process has some unique properties:
* It is normally short-lived, you want as high req/s as possible right?
* PD are normally propagated one-way. If you want to spawn a new
process, you can clone the PD.

Take Ale for an example, see:
http://github.com/ngocdaothanh/ale/blob/master/src/ale.erl

* Things in PD are set only ONCE (well, app_add_head and app_add_js
are accumalative).
* Keys in PD are normally literal. You can easily track back where a
value is set.
* Keys in PD are namespaced, i.e: {app, title}. Things of Yaws, things
of Ale, things of the app in PD are separated.
* When you want to put a thing in PD from a controller, you use
ale:app(Key, Value). When you want to get the thing out from a view,
you use ale:app(Key). You don't spam the PD arbitrarily, you use the
designated API.

This way, PD is like environment variables of a Linux shell session.
The environment is not for sharing mutable things, it is used for
setting things.

Ngoc


On Fri, Oct 30, 2009 at 2:39 PM, Max Lapshin <max.lapshin@REDACTED> wrote:
> Damn, I've programming Rails for many years and I really don't see any
> reason to use global hash tables!
> Explicitly passed data is very, very convenient and predictive way to
> glue SEPARATED layers.
>
> Using of PD in gen_server is its own internal way to live, I haven't
> seen this PD outside and I'm not going
> to think about it. But using PD to pass variables from controller
> layer to view layer in erlang is a VERY, VERY bad
> way of programming. It is a sufficient reason not to use such software
> at all, because it is a sign of very bad quality of other code.
>
> Explicit passing of data generated in controller, to view is:
> a) clear to understand
> b) clear to hook and modify, cache, etc.
> c) testable
> d) separatable (you may move templates from erlang to other application server)
>
> PD is:
> a) unclear, what is required and what is passed to template
> b) unmodifieable and unhookable. Business logic migrates to templates
> c) very, very hard to test
>