No, your question isn't too esoteric -- the dynamic scope / lifetime
of an object is basic to the semantics of the language.

What you *may* have overlooked in your
original question is that even if *you* don't
assign the result of a "new" request the underlying code may well have
saved it.

That would certainly be the case for
new Ajax.Request(...);  The code in
Ajax.Request.initialize() not only creates
this descriptor object but uses the object
to get the actual request sent.  It also sticks
that object in a queue of requests that are
awaiting replies so that underlying code
can, eg, insert the response in the DOM
and/or invoke any callbacks you may
have specified in your "new" request.

The underlying code won't lose a reference
to the Request object until it is completely
done with it -- you need not (even should not)
hold a reference to it unless you have a use
for it.

Hope that helps,


On Jan 24, 1:46 pm, "Jonathan Rosenberg" <> wrote:
> > On Jan 24, 2:53 pm, "Jonathan Rosenberg" <> wrote:
> > > My thinking was based on the many, many examples I've seen in the
> > > . . .
> > I don't think GC would ever allow such premature interruption.
> > `Ajax.Request` usually depends on `XMLHttpRequest` object internally.
> > That object, when initiated, is event-driven. Its responsibility is to
> > execute certain (previously "attached") handlers for certain events
> > (when processing server response). I'm sure it's marked as non-
> > collectable during its "lifetime".
> Ahhh ... so now you're starting to answer my original question: "How does js 
> do garbage collection?"  It's not as simple as it
> appears (at least, to me).
> So, can I assume that the naked "new Ajax.Request" object will be marked as 
> garbage once it's done its job?  Or is this up to each
> interpreter?  If so, it would seem to be good practice to hold a ref to the 
> object & set to null once it's served its purpose.
> > For example:
> > function F(x) {
> >   window.setTimeout(function(){
> >     alert(x);
> >   }, 3000);
> > };
> > new F('boo');
> > `F` is called as a constructor here and it creates an empty object.
> > That object can be immediately garbage collected by interpreter, but
> > constructor has already been executed by that time; It's done its deed
> > (by calling `window.setTimeout`) and can be safely discarded.
> This example is clear to me.  What's not clear is GC for objects that 
> initiate asynchronous behavior.
> I hope this isn't too esoteric for the list.  But I'm trying to understand GC 
> so that I don't leak memory in a long-lived
> application.
> > --
> > kangax
> --
> Jonathan Rosenberg
> Founder & Executive Director, Tabby's Place
You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to