«

In comp.lang.javascript message
<elfvlc$c7o$1$>, Sun, 10 Dec 2006 03:41:32,
Richard Cornford <> wrote:
>No you don't, and until you appreciate ho

>w very little you do understand
>about javascript and how utterly wrong most of your perceptions are, and
>go back an start learning it over, you never will.


You're such a windbag that you really ought to have been able to find
time to produce a FAQ update within the last year or so; but that we
probably should be grateful that you did not in fact do so.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

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.ActiveX");
}

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 "visualization" 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.

Richard Cornford wrote:

<snip>

> The next step in the demonstration is the code that can then be used by
> others to reproduce the effects and make the pint for themselves (or
> examined to expose flaws in the experimental process, so long as the
> reader knows what it is that the code is supposed to demonstrate):-

< snip the code demonstating the default GC mechanics in JavaScript>

Eh... An excellent application of the Chewbacca defense: you won the
case, he's innocent. Can we come back now to the question of who did
kill the girl? (inner function's closure memory leaking)?

Despite I already provided enough of samples in this thread, let's make
it one more time in application to string values: using your suggested
*proper* schema of rationale, materials, tools, expected results and
the actual results. Some later today if you don't mind.
(in a technical newsgroup the "sapienti sat" condition can be presumed
in many circumstances. Thusly a perpetual "non sat" from the opponent
may put the question if he's "sapienti" enough for the current topic...
Just a side thought unrelated to the thread...)

VK wrote:
> 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.

I don't know what your native language is, and I can't fault you for
anything lost in translation, but sometimes I can't really understand what
you're talking about.

> 1) "DOM circular reference" (DCR) cases are illustrated solely and
> exclusively by using closures.

No, they aren't. Look around. Closures just happen to be the most convenient
way to create the leak.

> 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() {...}
> }

Do you really think there's much of a difference, here?

> yet any author seems feel self-obligated to illustrate closures only
> with the second usage.

Because it's easier to read. And for all practical purposes, identical to
the first useage.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

Dr J R Stockton <> writes:

> In comp.lang.javascript message
> <elfvlc$c7o$1$>, Sun, 10 Dec 2006 03:41:32,
> Richard Cornford <> wrote:

[whatever]

> You're such a windbag that you really ought to have been able to find
> time to produce a FAQ update within the last year or so; but that we
> probably should be grateful that you did not in fact do so.

As a regular lurker, I can’t help exclaiming that clj has to be the best
NG ever, having it all – lots of useful insight (Cornford, Ley, Winter,
Honnen, Kruse et al), classical harmless patronizing (Lahn), pure
entertainment (VK) and toffee-nosed upper class twits (Stockton).

Here’s an overdue “thank you”.


--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

Eric B. Bednarz wrote:
> pure entertainment (VK)

You mean memory leaks is nothing but an entertainment to you? Oh
well... whatever use - still use...

Matt Kruse wrote:
> > 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.

> I don't know what your native language is, and I can't fault you for
> anything lost in translation, but sometimes I can't really understand what
> you're talking about.

I provided some samples to explain it. Briefly and plainly: the source
is bad (IMHO) when the matter is illustrated with such convoluted and
far of real life example that this source will be skept as irrelevant:
despite this source is more than relevant.
That all was in continuation of your "visual thinkers" statement which
I am agree with.

> > 1) "DOM circular reference" (DCR) cases are illustrated solely and
> > exclusively by using closures.

> No, they aren't. Look around. Closures just happen to be the most convenient
> way to create the leak.

You have then a reputable source where circular reference leaks are
illustrated as they are, without closures? Do you have a URL?

> > 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() {...}
> > }

> Do you really think there's much of a difference, here?

Why shoud anyone think otherwise? If only one kind of samples is
demonstrated: "*this* is closure, be aware of memory leaking" - then
another pattern may not trig the alarm when seen. "visual thinkers",
remember? Here is a good sample from another end:
<http://groups.google.com.au/group/comp.lang.javascript/msg/dce1775ff87cc186>

> > yet any author seems feel self-obligated to illustrate closures only
> > with the second usage.

> Because it's easier to read. And for all practical purposes, identical to
> the first useage.

How will anyone "see" it without parallel samples?

VK wrote:
>> No, they aren't. Look around. Closures just happen to be the most
>> convenient way to create the leak.
> You have then a reputable source where circular reference leaks are
> illustrated as they are, without closures? Do you have a URL?

One of the most often-cited urls when faced with the memory leak issue:
http://msdn.microsoft.com/library/de...k_patterns.asp
http://tinyurl.com/dkyec

>>> 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() {...}
>>> }
>> Do you really think there's much of a difference, here?
> Why shoud anyone think otherwise?

Because they are pretty much identical. One creates a function by name in
the execution context and points to it, the other creates an anonymous
function in the execution context and points to it. Same diff.

> If only one kind of samples is
> demonstrated: "*this* is closure, be aware of memory leaking" - then
> another pattern may not trig the alarm when seen.

But the above two examples don't even show a closure. Just inner functions.

>> Because it's easier to read. And for all practical purposes,
>> identical to the first useage.
> How will anyone "see" it without parallel samples?

You can give as many examples as you want. If it's all code, it's still not
"visual".

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

VK wrote:
> Richard Cornford wrote:
> <snip>
>> The next step in the demonstration is the code that can then
>> be used by others to reproduce the effects and make the pint
>> for themselves (or examined to expose flaws in the experimental
>> process, so long as the reader knows what it is that the code
>> is supposed to demonstrate):-
>
> < snip the code demonstating the default GC mechanics in JavaScript>

Are you suggesting that the reason that the memory increase of at least
2,000,000 MB that would be the logical consequence of creating 100,000
copies of a 20MB string is not observed because of garbage collection?
How does that work then, given that each string is assigned as the value
of an array element? In what way would garbage collecting the data
referred to by array elements while the array itself is still accessible
be "the default GC mechanics"? That sounds more like a serious bug to me
(or more likely another of your convenient fictions).

> Eh... An excellent application of the Chewbacca defense: you
> won the case, he's innocent. Can we come back now to the
> question of who did kill the girl? (inner function's
> closure memory leaking)?

You were the one concerned that the copying of large strings of data
would negatively impact on the issue, I have just demonstrated that you
were mistaken.

However, as you never made any actual statement bout "inner function's
closure memory leaking" beyond what was already well known what point
where you making?

> Despite I already provided enough of samples in this thread,

Samples of javascript doing what javascript is specified as doing are of
no use in demonstrating anything without some expiation of what
specifically is being demonstrated and how it is being demonstrated.

> let's make it one more time in application to string
> values: using your suggested *proper* schema of
> rationale, materials, tools, expected results and the
> actual results.

From you I won't believe it until I see it.

> Some later today if you don't mind.
<snip>

It seems to have been a very long day.

Richard.