 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / November 2006Is a closure in this code redundant?
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? > 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 > I'm a javascript noob and have a question concerning some code I've > come across that I'm trying to understand. [quoted text clipped - 13 lines] > 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. > 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? >> 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/ > > It allows the call-back function used to handle the XML HTTP response > > to call a method of a specific object instance. [quoted text clipped - 6 lines] > 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? >> [quoted text clipped - 4 lines] > 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. > 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. >> 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. >>> 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 [quoted text clipped - 10 lines] > > Richard. We have had problems when using ProtoType and the YUI grid together. That's about all so far...... User1014 said the following on 11/30/2006 11:07 AM: >> 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.  SignatureRandy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.