Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16141

Closures (was: silly question on closure)

Followups directed to: comp.lang.javascript

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:

> Stefan Weiss wrote:
>> On 2012-09-22 14:04, justaguy wrote:
>>> Question:
>>> 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.
> 
> There is, however, a caveat to intended closures of that kind that can
> turn out to be a disadvantage: The order of execution matters.  All
> variables used in the outer function must have the proper value *before*
> the outer function is called that returns the inner function.  (As the
> reader might recall, I have stumbled on that myself in JSX:object.js
> several times.)
> 
> In a library that uses closures for optimization and did not start out
> with the module pattern, this can mean that at one point the whole library
> must use the module pattern, i. e. all its definitions must be enclosed in
> one inner function.  (I am currently in the process of refactoring
> JSX:object.js like that so that I do not have to care any longer about
> execution order, potentially having to sacrifice backwards-compatibility
> along the way.)

And if the library has optional dependencies, this can mean that if you are 
using the module pattern, explicit initialization of the bound variable must 
be moved to the inner function (as Douglas Crockford has showed once in a 
very interesting presentation¹ on closures [1]):

  (function () {
    var dep;

    return function () {
      /*
       * or !dep && …;
       * depends on the initial and future value, code style,
       * and other factors
       */
      if (typeof dep == "undefined"
          && typeof optional != "undefined" && optional)
      {
        dep = optional.dependency.available.now;
      }

      if (typeof dep != "undefined")
      {
        /* do fancy things using `dep' */
      }
      else
      {
        /* do not so fancy things, without `dep' */
      }
    };
  }());

For a real-world example, in several JSX methods I am using features defined 
in other parts of JSX that are intentionally optional (like several other 
well-designed libraries, JSX is modular).  If I would initialize the outer 
local variable with the corresponding property (because I want to avoid the 
slower looking-up of the property down the scope chain and prototype chains 
starting with the Global Object every time the method is called), then that 
*optional* feature would become *mandatory*: the initializing code would not 
run without it.  Or if it would run, the initialization value might turn out 
to be `undefined' because the formerly optional part was not loaded yet, 
leading to a runtime error when the returned function is called, which is 
even worse.

This way, the initilization may still fail when the returned function is 
called, but at least I can debug that easily, and it will show up in unit 
test results.  The other way, the unit test of the optional feature would 
not be possible as the whole library could not be tested without it.

An additional advantage of this approach at initialization with references 
to *new* objects is that not only is the object only created once if the 
function is called; it is not created *at all* if the function is *never* 
called.  So a lot of memory can be saved without losing flexibility and 
versatility.  Which is a Good Thing.

(It turns out again that there are no silly questions, only questions asked 
the silly way.)


PointedEars
______
¹ You do not have to agree with all that he says (I certainly do not)
  to appreciate parts of it.

[1] 
<http://www.youtube.com/watch?feature=player_detailpage&v=ya4UHuXNygM#t=1595s>
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-22 05:04 -0700
  Re: silly question on closure Stefan Weiss <krewecherl@gmail.com> - 2012-09-22 18:18 +0200
    Re: silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-22 18:41 -0700
    Re: silly question on closure Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-24 01:10 +0200
      Closures (was: silly question on closure) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-24 13:14 +0200
      Re: silly question on closure Stefan Weiss <krewecherl@gmail.com> - 2012-09-27 05:04 +0200
        Re: silly question on closure Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-27 20:50 +0200
          Re: silly question on closure Stefan Weiss <krewecherl@gmail.com> - 2012-09-27 21:29 +0200
  Re: silly question on closure "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-22 20:00 +0200
    Re: silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-22 18:42 -0700
      Re: silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-23 07:31 -0700
        Re: silly question on closure Stefan Weiss <krewecherl@gmail.com> - 2012-09-23 18:49 +0200
          Re: silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-23 13:33 -0700
          Re: silly question on closure justaguy <lichunshen84@gmail.com> - 2012-09-23 13:38 -0700
            Re: silly question on closure Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-24 20:49 +0200
    Re: silly question on closure Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-24 01:14 +0200
  Re: silly question on closure dann90038@gmail.com - 2012-09-23 15:37 -0700

csiph-web