Matt Kruse wrote:
<snip>
Richard, I think a diagram like above would help people to understand the
concept better, since many programmers are visual thinkers.
With some explanation of what is "visual thinker" in this case. I'd
like to avoid an impression that the "real programmers" (excluding
myself from this list - of course) are some low-IQ people: so the
matter gets on them only through Shockwave movies, blackboard drawings
and color balls and cubes :-)
This "visuality" is no much different from the common human mind
paradigm of making tools: first forming some mental model of the
desired tool - and then applying this model to the surrounding entities
in search of the most close to the model. Say if you need a piece of
wire to fix something, you first "see" the wire of the needed diameter
and length and then quickly looking around the garage: "too short...
not a wire... here!"
The only difference in programming that the "mental model" is some
programming entity you are working with or seeking to implement. The
"garage" then is paper-printed or Web resources you're quickly passing
over: "not my case... not that... here!"
Respectively an info source is bad not only if it's incomplete or if it
contains some wrong info. An info source is bad as well if it
"obfuscate" the model it describes up to the state of no match to the
"mental" model of the researcher: despite both models may be identical
or very close. Of course by carefully reading and studying the source
the researcher will find the match. But most of the time programmers
have no luxury to profoundly study some source which is "visually" not
what they after: with the only hope that some later deeper inside it
will be what they do need: instead "not my case... not that...
further".
In application to the discussed matter the quality of the current
information on the Web (from the criterion formed above) is sub-optimal
to say the least:
1) "DOM circular reference" (DCR) cases are illustrated solely and
exclusively by using closures. That makes people believe that unless
where is an inner function, DCR is not possible: "not my case...
further...".
2) MSDN graphs illustrating memory leak situations show such
complicated obfuscated relations that the first "visual" reaction
is "in my entire life I did not code such crazy sh** like that" :-)
So it hides the fact that the situation can be as primitive as two
lines of code one is using on the daily basis. There is a trend for
some reason to demonstrate not some real case - but an imaginary
situation brought "ad ultima Thule" (up to the extreme borders). The
sample you proposed to your friend is a bit of this kind IMHO.
3) Function expressions like:
function foo(elm) {
this.bar = function(){...}
// or
// elm.onclick = function(){...}
}
are taking ~99% "of the market" as opposed to ~1% inner function usage
like:
function foo(elm) {
this.bar = bar;
// or
// elm.onclick = bar;
function bar() {...}
}
yet any author seems feel self-obligated to illustrate closures only
with the second usage. It forms the impression that the first usage is
not really a closure - or some "harmless" closure (illustrated by
myself and by OP's question).
4) MSDN-specific: MSDN guys just cannot leave w/o that ActiveX. Even if
they are talking about something as universal as local vs global
variables: even then they still illustrate it with something like
var foo = new ActiveXObject(" ILove.ActiveX") ;
function Foobar() {
var foo = new ActiveXObject(" IReallyLove.Act iveX");
}
How much of very useful info was missed - being mistakenly taken as
ActiveX-specific - I'm scared to think about.
This way a really proper "visualizat ion" of a model has to be IMHO:
1) Illustrating one topic only at one time;
2) Illustrating exactly the topic spelled in the (sub)title;
3) Illustrating the topic on the most casual real life sample adequate
to the period of time the sample was made.