Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3738235.beI7O1F77D@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Thu, 27 Sep 2012 20:50:15 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <7227299.QoKgMUOf8L@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 62 NNTP-Posting-Date: 27 Sep 2012 20:50:15 CEST NNTP-Posting-Host: ac0bd732.newsspool3.arcor-online.net X-Trace: DXC=?Ta On 2012-09-24 01:10, Thomas 'PointedEars' Lahn wrote: >> Stefan Weiss wrote: >>> On 2012-09-22 14:04, justaguy wrote: >>>> The closure takes so many lines while the function has only 2 lines to >>>> get the same thing done. So, the question is, why do we use closure? >>> >>> You don't, just like you don't actually use "Hello, world" in production >>> code. This was obviously just an example for how closures work. If this >>> was code intended for actual use, your "just a function" variant would >>> be better suited (provided it only returned the value, like in the >>> "closure" example). >> >> You are mistaken as you are overlooking that creating that Array instance >> and populating it with elements requires resources – memory and runtime. >> Since we have only automated garbage collection, and the function may be >> called a number of times, it is better to use a closure here, so that the >> object would only be created, and the array only populated, once. > > I would say that depends on the use case. Of course it does. > I have no doubt that closures can offer performance benefits even with a > simple 4-element array like this, but unless you're running the function a > million times in a tight loop, the difference will be hardly noticable. Of course. You are missing the point. > There's a often a tradeoff between legibility and performance. > Introducing temporary variables, helper functions, layers of > indirection, etc, can all hurt performance, but we still do it because > it helps us keep our code clean, understandable, and maintainable. False dichotomy. > In the vast majority of cases, JS performance is not a problem > (anymore). You are very much mistaken. > In this particular case, the goal was "understanding closures". It's a > fair assumption to make that the code was not running in a tight loop, and > that the OP was not overly troubled by the performance of his script. I have disputed your assertion that closures are to be avoided with a two- line function because they would not be worth it in any case. > You're writing a general purpose library, the OP is learning JS. Your > goals are different. Recommending the closure style whenever possible, > regardless of circumstances, smacks of premature optimization. Which is why I am not doing that. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann