[erlang-questions] Process scope variable
Tue Feb 17 18:37:00 CET 2015
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.
More information about the erlang-questions