Is a closure in this code redundant?

[User1014]

I'm a javascript noob and have a question concerning some code I've come
across that I'm trying to understand.

Here is a snippet of the relevant section:

(snip)
var closure = this;
var xhr = new Ajax.Request(this.Url,
{
method: 'post',
onComplete: function(ajaxResponse) { closure.doStuff(ajaxResponse); }
});
(snip)

When you create a function inside a function like this I know a closure
is created but what I don't understand is how this closure is used in
the above example. I've only seen examples where a reference to the
first function is returned so that it can be invoked again at a later
time with the same local variables as were created initially.

However in the above a callback mechanism is used when executing
doStuff() and the function reference would appear to be a local
reference to the inner function (onComplete)

i.e. isn't a closure redundant in the above code?

What am I not understanding here?

[pcx99]

User1014 wrote:

i.e. isn't a closure redundant in the above code?

What am I not understanding here?

You're absolutely right. Closure is redundant. You SHOULD be able to
do this.doStuff(ajaxResponse). However javascript has a few odd
idiosyncrasies and one one is that to call another procedure inside the
object in this manner you very often times need a variable like closure
to make the call.

Often when browsing object-oriented javascript code you'll find this
workaround expressed as such:

var that=this;

---------------------------------------------------------------------------
http://www.hunlock.com -- Permanently under construction (And proud of it!)
$FA

[Richard Cornford]

User1014 wrote:

I'm a javascript noob and have a question concerning some code I've
come across that I'm trying to understand.

Here is a snippet of the relevant section:

(snip)
var closure = this;
var xhr = new Ajax.Request(this.Url,
{
method: 'post',
onComplete: function(ajaxResponse) { closure.doStuff(ajaxResponse); }
});
(snip)

When you create a function inside a function like this I know a closure
is created but what I don't understand is how this closure is used in
the above example.

It allows the call-back function used to handle the XML HTTP response
to call a method of a specific object instance.

I've only seen examples where a reference to the
first function is returned so that it can be invoked again at a later
time with the same local variables as were created initially.

That is what this example is doing, though it is doing it in order to
mitigate significant design flaws in the library that contains
Ajax.Request.

However in the above a callback mechanism is used when executing
doStuff() and the function reference would appear to be a local
reference to the inner function (onComplete)

i.e. isn't a closure redundant in the above code?

No it is not. The function object will know nothing about the object
referred to by - this - at the point when it was defined later on when
it is called, so if it needs to refer to that object instance it needs
another way of referencing it.

What am I not understanding here?

Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

Richard.

[User1014]

* Richard Cornford wrote:

It allows the call-back function used to handle the XML HTTP response
to call a method of a specific object instance.

I don't see how the code is different to:

this.doStuff(ajaxResponse);

Excuse my ignorance but I'm from a C# background and am obviously
missing something in how local variables and functions on the stack are
retained via the closure mechanism.

>What am I not understanding here?

Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

No I've not heard that before about Prototype. Can you suggest an
alternative?

[Douglas Crockford]

User1014 wrote:

* Richard Cornford wrote:

>It allows the call-back function used to handle the XML HTTP response
to call a method of a specific object instance.

I don't see how the code is different to:

this.doStuff(ajaxResponse);

There is an error in the ECMAScript standard which causes this to be bound to
the wrong value. In this case, this will be bound to the global object, not to
the object of interest.

The workaround is to assign this to a variable of the outer function, something like

var that = this;

Then in the inner function we can safely write

that.doStuff(ajaxResponse);

http://javascript.crockford.com/

[Richard Cornford]

User1014 wrote:

* Richard Cornford wrote:

It allows the call-back function used to handle the XML HTTP response
to call a method of a specific object instance.

I don't see how the code is different to:

this.doStuff(ajaxResponse);

Excuse my ignorance but I'm from a C# background and am obviously
missing something in how local variables and functions on the stack are
retained via the closure mechanism.

Javascript derives its - this - values form how a function is called,
dynamically at the point of calling it. When the function in question
is called (and no matter how it is called) there is no mechanism in
that context that will refer to the specific object instance in
question, so the function object itself has to know how to refer to the
object instance. It does that through the scope chain of the function,
by referring to the value assigned to - closure -.

<URL: http://jibbering.com/faq/faq_notes/closures.html >

>>What am I not understanding here?

Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

No I've not heard that before about Prototype. Can you suggest an
alternative?

The best starting point for that answering that sort of question is an
understanding of the context in which the end result is to be used, and
what the end result is supposed to do. No blanket "use this" or "use
that" advice given without that information is good advice.

Richard.

[User1014]

* Richard Cornford wrote:

Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

This statement does worry me a little because we use ProtoType quite
extensively. Is it really all three of these things that you describe??

The last one worries me the most.

[Richard Cornford]

User1014 wrote:

* Richard Cornford wrote:

>Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

This statement does worry me a little because we use ProtoType quite
extensively. Is it really all three of these things that you describe??

The last is a question of opinion (mine is expressed above), the others
are objective facts.

The last one worries me the most.

OK.

Richard.

[Randy Webb]

User1014 said the following on 11/30/2006 11:07 AM:

* Richard Cornford wrote:

>Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

This statement does worry me a little because we use ProtoType quite
extensively. Is it really all three of these things that you describe??

Absolutely.

The last one worries me the most.

It should.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[User1014]

* Richard Cornford wrote:

User1014 wrote:

>* Richard Cornford wrote:

>>Hard to say. I can assume that you don't understand how very poor the
Prototype.js library is (being non-cross-browser, non ECMAScript
compliant, and ludicrously deigned).

This statement does worry me a little because we use ProtoType quite
extensively. Is it really all three of these things that you describe??

The last is a question of opinion (mine is expressed above), the others
are objective facts.

>The last one worries me the most.

OK.

Richard.

We have had problems when using ProtoType and the YUI grid together.
That's about all so far......