View source for Closures (programming)


{{programming}}

This is about the programming concept - not mathematical closures, physhological closure, or any other kind.


=Definition=

Closures are easy enough to define ''technically'', but harder to explain ''usefully''.


Say, [http://foldoc.org/foldoc.cgi?query=closure Foldoc says] ''"a closure is a data structure that holds an expression and an environment of variable bindings in which that expression is to be evaluated. The variables may be local or global."''


Even if you've reread that a few times, or even already understand closures, that is ''still'' not very clear. So:

=Technical side=

In a lot of cases, the rough intuition for a closure is a function that remembers (part of) the scope it was defined in. 

...which matters only when a function can be used in other scopes, so this is mostly a thing where functions/lambdas are [[first class citizens]], i.e. things that can be handed around.



'''Example still on the fairly technical side (skip if you want something more practical)'''

Consider the following pseudocode {{comment|(valid javascript, but pretend you don't know that, or whether it supports closures)}}:
<syntaxhighlight lang="javascript">
var add = function(a) {
  return function(b) {
    return a + b;
  }
}

//create new function
var add10 = add(10);

//test it:
add10(5);   // 15, yay
</syntaxhighlight >



Note that {{inlinecode|a}} is declared in the outer function's scope (by being a parameter on it, but that doesn't really make a difference). 

The inner function gets access to {{inlinecode|a}} because local/nested functions gets its own scope, but also to see their parent's function's scope. {{comment|(which is often half the reason nested functions themselves are useful)}}.


On top of that, the above is apparently a language that allows you to return functions.

Which means it needs to deal with the possibility that a function can get handed out of the scope it was defined in. Above, we've handed that inner function outside.


What would that do to the scopes involved? In this case, after that inner function is returned and handed out, how does it find {{inlinecode|a}}?

{{comment|(There's a few different ways you could argue that should work. It is an interesting exercise to work them out, if you care to learn more about how scope works in different execution models)}} 

Say, a language that allows nested function but not closures would probably consider this invalid code {{comment|(the precise reasons would vary a little with how exactly that languages thinks about scope)}}.


A fairly sensible alternative is to say something like "everything that is in scope while a function was defined, will be available when you call {{inlinecode|add}} from anywhere else." 

In the example, that means the anonymous inner function inside add will get a reference to {{inlinecode|a}}.

Which means the above example is working Javascript code.



{{comment|(You may notice that this is not the best example for when closures are useful. If the language supported function nesting but not closures, you could get around it just by handing a into the inner function explicitly, thereby binding it into the inner function's scope. Not the cleanest solution if you have a lot of them, but certainly workable.)}}


<!--
<syntaxhighlight lang="javascript">
// The following is does all of the same, but more verbosely
function g(a){
   function add(b) { //the wrapped function
      return a+b;
   }
   var add10 = add(10); //could be anonymous, given a name just for readability
   return add10;
}


//if you call g later:
g(5)
</syntaxhighlight >


{{comment|(local scope are stack-only and stops existing - efficient but inflexible)}} versus more flexible ones {{comment|(scope are objects kept around - flexible but invites various issues)}})}}.

Options include:
: a would simply be an unbound variable outside of the scope
:: meaning undefined behaviour 

: remember the original scope
:: this means every call of add creates a new scope that must exist until the returned function is destroyed

: copy things into the returned function's scope
:: often made immutable, or 
:: limits the uses 


In simple execution models, scope belongs more to the point of execution.
Globals variables  are always available and always the same)
locals are a a bunch of bytes placed onto the stack that are created when the function is entered,
and stop existing once it returns.

This is why a thread has its own 

You could say the scope belongs to the function, rather than to the current point of execution {{comment|(which is effectively true in simpler execution models - again, depends on the language)}}.

Sure, returning functions has limited use in languages that don't support closures.
Whether it is nested like above, or referenced some other way, makes little difference (except for the difference in actual scope).

-->

=Examples=
==Javascript uses==
<!--

'''Browser / DOM stuff'''

In browser-based javascript, closures will e.g. make it easy to adding (anonymous) event handlers to DOM elements.

Say you have the code:
<syntaxhighlight lang="javascript">
function set_class_on_mouseover(new_class) {
  var divs     = document.getElementsByTagName('div');
  for(var i=0;i<divs.length;i++){
    divs[i].addEventListener(
      'mouseover',
      function(e) { this.setAttribute('class',new_class); },
      false
    );
  }
}
window.onload=set_class_on_mouseover('red'); 
</syntaxhighlight >

set_class_on_mouseover is executed once, and puts that inner function on all divs's mouseover handler.

In that inner function, <tt>new_class</tt> is of interest. 
Without closures it simply wouldn't be in scope outside of <tt>set_class_on_mouseover()</tt> (and this code makes no sense at all).

With closures, that inner function remembers new_class from set_class_on_mouseover's scope.


Note this does have implications to the garbage collector.
Things defined in set_class_on_mouseover won't be collected until there are no references, from closures or otherwise, and closures can be rather sneaky references.



'''IIFEs and the module pattern'''



-->

==Python use==
Closures exist in python since 2.2. 


'''Example: if you do a lot of sorting'''

One nice thing it allows is sorting an array-in-array structure by arbitrary columns, 
without having to hardcode for each specific case.

Say you do a lot of sorts on different things, and find yourself typing things like:
<syntaxhighlight lang="python">
matrixish.sort( lambda a,b: cmp(a[2],b[2]) )
</syntaxhighlight >


Instead, you can 
<syntaxhighlight lang="python">
# define this once
def nth_column_lex(n):
    return lambda a,b: cmp(a[n],b[n])

# and use it any amount of times like:
matrixish.sort( nth_column_lex(2) )
</syntaxhighlight >



'''Example: if you do a lot of filtering'''

You can use python closures to support syntactic sugar such as:
<syntaxhighlight lang="python">
def paid_more_than(amount):
    amount += 10 # ...cheapskate hack
    return lambda item: item['salary'] > amount

fair      = paid_more_than( 140 )  
expensive = paid_more_than( 160 )
# fair and expensive  are functions that return true or false, so can be used in filter()

employees=[ {'salary':150}, {'salary':170,'isManager':True}, {'salary':120}  ]
print(  filter( fair,      employees )  )
print(  filter( expensive, employees )  )
</syntaxhighlight >

<tt>fair</tt> and <tt>expensive</tt> are newly created functions {{comment|(here via lambda because it's brief that way)}}, and their variable 'amount' is based on the value that it had in its defining context - which is the respective executions of <tt>paid_more_than</tt>. 

This makes them independent (no side effects, e.g. no outside alterations of amount is possible).

This also means you can use them in list comprehensions and generator functions {{comment|(ignore them if you don't know them yet; think of it them as list creators-and-filters)}}:
 result = [e  for e in employees  if fair(e)]
Note that fair(e) is more or less like saying <tt>paid_more_than(140)(e)</tt>, except that that would create a closure function every execution. 


Since the non-generator/non-closured alternative to this is basically a function with a for loop, it's short ''through'' closures, though only if you actually use the paid_more_than thing regularly.

Of course, the above example is a little silly by being one-shot, as the for loop:
<syntaxhighlight lang="python">
amount=140
for e in employees:
    if e['salary']>amount:
        print e
</syntaxhighlight >
...is good enough.

=Possible caveats=


==Read-only scope issues==

<!--
Some languages do closures, but make them read-only. 

This tends to be fine for a lot of uses, but defeats some others.


Consider this python code:
<syntaxhighlight lang="python">
def foo():
    x='a'
    def bar():
        x='b'
    bar()
    print x
</syntaxhighlight >

{{comment|(This isn't even a closure construction, just a local function, but it carries through to closures.)}}


You might expect that foo()'s call of bar() to assign and therefore later print 'b'.

((The internal function <tt>bar</tt> is even executed in the same scope it is defined in, but that's moot; ))


Yes, bar sees foo's scope, but it's read-only to bar.
: You may expect it to either bork at runtime. 
: Or create a variable local to bar.
It turns out it [[Python_notes_-_syntax_and_language#Note_on_closures|does the latter]]. 

But neither would be what you probably wanted anyway.

{{comment|(This also implies another detail: If you want to do something like <tt><nowiki>variable+=1</nowiki></tt>, and that implies creating a new local variable, that may be functionally fine, except it makes it easier to access it before trying to write it)}}
-->

==Nested closures==
<!--

Some things do closures but don't let you nest them, 
or get much messier when you nest them.

This matters e.g. in a few places in javascript,
where certain styles of writing make it confusing what {{inlinecode|this}} refers to, and whether that changes.

Consider 
: nesting callbacks used to be common,
: pre-ES6 classes (e.g. the constructor)



https://javascript.plainenglish.io/tws-020-how-to-keep-your-code-tidy-by-avoiding-nested-closures-7d9ecd881484
-->

==Easier memory leaks==
<!--

Years ago, browsers had JS and DOM garbage collectors that were not well integrated with each other,  
which made it ''really'' easy to make references back and forth that means collection happened later,
or not at all.

Certain OO modeling but in particular certain use of closures 
made that harder to avoid, or track down,
which meant closures were actively a bad idea, at least in SPAs.


These days, the GCs are much more integrated, so it's harder, though still possible, to make such mistakes.



https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

-->



[[Category:Programming]]
[[Category:Explanation]]