Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: codeHan...@yahoo.ca (rh)
Newsgroups: comp.lang.javascript
Subject: Re: closures, what are they good for?
Date: 28 Apr 2003 16:30:10 -0700
Organization: http://groups.google.com/
Lines: 52
Message-ID: <290e65a0.0304281530.c02e86e@posting.google.com>
References: <8d54528badb2f585a37b76c4c3e19694@news.teranews.com> <4r4q89c7.fsf@hotpop.com> <290e65a0.0304271355.3bc9eda7@posting.google.com> <9amoav0963mav6cb705c63a3sn97es8laj@4ax.com> <b8i00c$o5k$1$8300dec7@news.demon.co.uk> <b8i6pk$np$1$8300dec7@news.demon.co.uk> <b8jm5j$69h$1$8300dec7@news.demon.co.uk>
NNTP-Posting-Host: 216.232.172.51
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1051572611 25406 127.0.0.1 (28 Apr 2003 23:30:11 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 28 Apr 2003 23:30:11 GMT

"Richard Cornford" <Rich...@litotes.demon.co.uk> wrote in message news:<b8jm5j$69h$1$8300dec7@news.demon.co.uk>...
> Richard Cornford wrote in message ...
> <snip>
<snip>

> - as it does considerably less work on each invocation of the inner
> function. However it does now assume that the reference to the function
> that is stored in the public static member of the constructor is not
> changed by other scripts.
> 
> Although, storing a reference to a private method of an object instance
> will prevent garbage collection of the object instance (at least until
> the page unloads) so the 'tempFunc' array (or the function reference
> within it) might have to be actively nulled if the cyclic reference to
> activeX and HTML element problem that Steve van Dongen raised is likely
> to be significant.
> 
> Richard.

(My version of the thread currently looks as:

\-11 Lasse Reichstein Nielsen 22 Apr 2003 
  \-12 Richard Cornford 27 Apr 2003 
    \-13 Richard Cornford 27 Apr 2003 
      \-14 Richard Cornford 28 Apr 2003 

missing my prior post, and apparently one from Steve van Dongen, so I
may not be tracking correctly.)

Your extension here and above is interesting and instructive. Not sure
how practical or necessary it is though.

Another objection that may well arise is that you appear to have
converted private functions into a public functions (which I also did,
perhaps, by handing off the reference to setInterval -- but I
considered it trusted) by adding the accessible references to the
constructor object.

That suggests to me that intervalEvent really ought to be
this.intervalEvent, i.e., a public function to begin with, just so
everything stays clear and consistent regarding public vs. private.
With that change you should be able to store references to the primary
objects, rather than references directly to inner functions, and still
be able to get to the handler through the eval of a string generated
by the .toString invocation.

That doesn't solve the problem of creating additional references,
however.

(By the way, thanks for cleaning up the slightly brain-dead iteration
control in my example. I debated about fixing it prior to posting, but
wasn't capable at the time ;-)).