[erlang-questions] Process scope variable

[zxq9]

On 2015年2月17日 火曜日 18:08:37 you wrote:
> > you're missing the distinction between messages and arguments -- they are
> > not the same thing.
> I used the word "message" in a misleading way. I did not mean
> "message" as erlang message sent to another process. simply alleged to
> "message" (a "tweet" if you prefer) passed from person A to person B

I don't prefer. Its still not the same thing.

> this state passing clutters the code and makes refactoring difficult.
> I prefer to only pass the args the fun actually needs. If some other
> fun down the line needs the state, let it get it directly.

The goal is to be explicit, so that you can look at exactly, and only, the 
inputs to a function on a single call and be able to know/test its outcome 
precisely unless it has side effects.

When you say "let it get it directly" you are introducing a side effect, 
whether that is fetching something from the process dictionary (which is at 
least data internal to the process) or fetching data from an external 
resource, it is not a value that sticks out the moment something crashes 
because of unanticipated data used in the function somewhere because it was 
*not* one of its inputs. Even if debugging and readability were the only 
reasons for this, they would be good enough reasons to handle as much data 
within a process as I could as arguments instead of sideband acquisitions of 
additional non-argument data mid-stride through stage V of N expressions in 
function X of Y in a chain of calls.

This style of thinking avoids subtly putting too much explicit responsibility 
in a single function. Instead of getting called, fetching a value, performing 
some computation, sending a response to the data fetch source, and returning a 
value in a single monolithic function ("OK, so it was called here with X and Y 
but it crashed... hmmm... Oh, Z? Where did that come from? Oh, fetching from 
source Q... wait, what part of that didn't work out? Oh, that was the process 
dictionary? But it wasn't changed yet, so not fetched yet, that's another 
place... mmm..."  <- waste of the only resource you were born with), have a 
function that does each of these, and a single function that wraps the concept 
so you can at least keep track of what is going on. A (very rough heuristic) 
symptom is frequently noticing a few >20 expression functions instead of 
several <10 expression functions.

If you find yourself writing an excessive number of functions that simply 
receive arguments to pass them through it may be a good idea to ask yourself 
why your programs are winding up this way before you start hunting for ways to 
dance around the design decisions that underly the system. Sometimes it isn't 
easy to avoid passing, say, a gen_server's #state (or something similar) along 
here and there, but usually refactoring for functional generalization also 
winds up yielding code that does a lot less argument passthrough.