|Perl: the Markov chain saw|
My question was also intended to be a pedagogical one, though I might or might not have conveyed that notion.
Perhaps I rendered the wrong idea when I used words like "characterize" or "procedurize" (I don't know if such word even exists).
Design is a creative process. I don't think anyone can "mechanicalize" (another makeup word?) it. But people certainly have explicit or implicit theories behind their minds guiding their thinking and design process.
Perhaps what I'm trying to ask is, what are the guiding theory of "closure"?
Stated "theories" accompanied with examples are important when teaching someone something new, just as foreign language teachers teach grammar. People who already speak the language don't think grammar. Programmers who already master the trade don't think of what paradigm, theory or style they're actually employing.
But for a student, he might be more explicitly and discretely thinking of "encapsulation," "interfaces," "inheritance," etc. one by one, rather by utilizing every appropriate thing dexterously without thinking of all those "labels." It's just a natural learning process.
In reply to Re: Re: Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)