Simon Willison's Weblog: closures

What are some JavaScript concepts that took you the longest to understand?

2013-07-30T12:09:00+00:00

My answer to What are some JavaScript concepts that took you the longest to understand? on Quora

Closures, prototype inheritance, and the "this" keyword.

Once you understand those three, you know most of what there is to know about the JavaScript language in my opinion (with the exception of some of the newer language features like iterators and generators).

Tags: closures, javascript, quora

10 Uses for Blocks in C/Objective-C

2009-11-16T14:27:15+00:00

10 Uses for Blocks in C/Objective-C

Part of the Cocoa for Scientists series, which is by far the best free Objective-C / Cocoa tutorial I’ve seen anywhere.

Tags: blocks, closures, cocoa, macos, objective-c, science

And so it goes, around again

2009-09-03T09:46:33+00:00

And so it goes, around again

Charles Miller on Java, pointing out that if you don’t have closures and first-class functions you end up having to add band-aid solutions and special case syntactic sugar. Python’s lack of multi-line lambdas leads to a similar (though less pronounced) effect.

Tags: charles-miller, closures, java, programming-languages, python

Mac OS X 10.6 Snow Leopard: the Ars Technica review

2009-09-01T19:05:25+00:00

Mac OS X 10.6 Snow Leopard: the Ars Technica review

The essential review: 23 pages of information-dense but readable goodness. Pretty much everything I know about Mac OS X internals I learnt from reading John Siracusa’s reviews—this one is particularly juice when it gets to Grand Central Dispatch and blocks (aka closures) in C and Objective-C.

Tags: apple, blocks, c, closures, grandcentraldispatch, john-siracusa, macos, objective-c, snowleopard

Why I don't love JavaScript's Module Pattern

2009-04-30T19:59:39+00:00

Why I don't love JavaScript's Module Pattern

Jonathan Snook points out that the module pattern (where private functionality is hidden in a closure and only public methods are revealed to outside scopes) makes code a lot harder to debug. I use the module pattern for pretty much everything, not because I want to keep stuff private but more to avoid any chance of leaking out in to the global namespace. If I need to debug a value I temporarily assign it as a property on the global window object.

Tags: closures, debugging, javascript, jonathan-snook, modulepattern

why's potion

2009-01-08T18:37:34+00:00

why's potion

why’s latest project is a small, fast language (JIT to x86/x86-64) which seems to take ideas from Ruby, Lua, Python and who knows where else. Everything is based around objects, closures and mixins, with the delightful inclusion of scoped mixins so you can modify an object only within a certain module (hence avoiding Ruby’s action-at-a-distance problems).

Tags: closures, jit, languages, lua, mixins, potion, programming, ruby, whytheluckystiff

Blocks in Objective-C

2008-12-29T19:38:08+00:00

Blocks in Objective-C

Closures are coming soon to Objective-C - interesting syntax, a regular curly brace block preceded by a caret ^{ ... }.

Tags: blocks, closures, objective-c, programming, syntax

php: rfc: closures

2008-07-19T22:58:45+00:00

php: rfc: closures

I never thought I’d see the day, but a patch adding closures to PHP has been both proposed and accepted! Looks like a solid implementation—the syntax is similar to JavaScript but makes explicit which variables are to be captured. As with much of PHP, values are copied in to the closure by default but you can use an ampersand to specify JavaScript-style pass-by-reference instead.

Via Keeping Current With PHP

Tags: closures, functional-programming, javascript, php

Module Pattern Provides No Privacy... at least not in JavaScript(TM)

2008-06-27T19:01:34+00:00

Module Pattern Provides No Privacy... at least not in JavaScript(TM)

JavaScript variables hidden inside a closure aren’t as hidden as I thought—it turns out you can pass a closure as the second argument to eval (at least in Firefox) and “steal” private variables back out of it.

Via Ajaxian

Tags: closures, firefox, javascript, modulepattern, pete-michaux

IE JScript Performance Recommendations Part 3

2007-01-09T11:48:10+00:00

IE JScript Performance Recommendations Part 3

Once again, Microsoft’s official advice is to avoid closures entirely rather than learn how to use them safely. Sigh.

Tags: closures, internet-explorer, javascript, microsoft

JavaScript Closures for Dummies

2006-07-06T10:01:03+00:00

JavaScript Closures for Dummies

Not quite for Dummies as it talks about C pointers, but a valiant attempt.

Tags: closures

Closures And Highly Readable Sequence Sorting Customization

2006-01-24T00:23:08+00:00

Closures And Highly Readable Sequence Sorting Customization

Really neat usage of closures in Python.

Tags: closures

Getting Funky With Scopes and Closures

2006-01-23T10:27:30+00:00

Getting Funky With Scopes and Closures

Mark Wubben has some neat tricks up his sleeve.

Tags: closures

Leak Free Javascript Closures

2005-10-27T13:52:25+00:00

Leak Free Javascript Closures

This is some pretty brilliant JavaScript voodoo.

Tags: closures

Another practical use for JavaScript closures

2005-07-31T13:08:59+00:00

Another practical use for JavaScript closures

Create private methods by hiding them in a closure.

Tags: closures

Martin Fowler on Closures

2004-09-09T07:51:10+00:00

Martin Fowler on Closures

They really aren’t that complicated once they’re explained well.

Tags: closures, martin-fowler

XMLHttpRequest and Javascript Closures

2004-05-27T00:23:03+00:00

XMLHttpRequest and Javascript Closures

Harry gets intimate with Mozilla’s XMLHttpRequest object.

Tags: closures

Javascript Closures

2004-05-26T16:52:21+00:00

Javascript Closures

Notes on Closures.

Tags: closures

Closures and executing JavaScript on page load

2004-05-26T07:09:29+00:00

Closures and executing JavaScript on page load

I’ve tried to explain closures on my SitePoint blog, using addLoadEvent() as an example.

Tags: closures

Executing JavaScript on page load

2004-05-26T06:30:37+00:00

Peter-Paul Koch recently wrote:

In my opinion, recent advances in JavaScript theory call for the removal of the event handlers that some Web developers-and all WYSIWYG editors-deploy in large masses in their XHTML files, where they don’t belong.

PPK is talking about inline event attributes such as the infamous onclick="" and onmouseover="" which have infested our HTML ever since Netscape introduced JavaScript back in version 2.0 of their browser. The alternative to these handlers is to add event handlers to elements after the document has loaded. PPK has detailed coverage of the various ways of doing this on his QuirksMode site.

In my work with unobtrusive JavaScript, I've found that by far the most common action I take is "registering" a script to be executed once the page has finished loading. There are a number of ways of doing this, which I described in my article Enhancing Structural Markup with JavaScript. Unfortunately, none of them are perfect if you wish to write truly reusable scripts.

For a script (such as my blockquote citations script discussed in the article) to be properly reusable, it needs to behave nicely in the presence of other scripts. This means that assigning a callback function directly to the window.onload handler is out of the question as doing so will over-ride previously assigned callbacks from other scripts. The correct way of adding a handler to an event without over-riding other handlers is to use modern event attachment method, which sadly differ between IE/Windows and other browsers. Scott Andrew's addEvent function handles the differences for you but comes with one major and rarely discussed drawback: it fails silently in IE5/Mac. If you care about the many Mac users still on OS9, you need to support that browser.

Anyway, I believe I've found a solution. Check this out:


function addLoadEvent(func) {
  var oldonload = window.onload;
  if (typeof window.onload != 'function') {
    window.onload = func;
  } else {
    window.onload = function() {
      if (oldonload) {
        oldonload();
      }
      func();
    }
  }
}

addLoadEvent(nameOfSomeFunctionToRunOnPageLoad);
addLoadEvent(function() {
  /* more code to run on page load */ 
});

The addLoadEvent function takes as an argument another function which should be executed once the page has loaded. Unlike assigning directly to window.onload, the function adds the event in such a way that any previously added onload functions will be executed first.

The way this works is relatively simple: if window.onload has not already been assigned a function, the function passed to addLoadEvent is simply assigned to window.onload. If window.onload has already been set, a brand new function is created which first calls the original onload handler, then calls the new handler afterwards.

addLoadEvent has one very important property: it will work even if something has previously been assigned to window.onload without using addLoadEvent itself. This makes it ideal for use in scripts that may be executing along side other scripts that have already been registered to execute once the page has loaded.

I've tested the above code successfully on IE 5, 5.5 and 6 for Windows; IE 5 and Safari for Mac; Opera 7.5 and FireFox on Mac (which should mean it works with those browsers on Windows as well). Opera 6 for Mac failed the test but has poor JavaScript support anyway and is hopefully becoming more and more rare now that Opera 7 has matured.

I've created a test page for the function. I'd be interested to here any bug reports from browsers I haven't covered.

I'm still considering ways in which this technique could be extended to work for generic events rather than just page loads. The challenge there would be to ensure that information about the event itself was passed to the event handlers in a consistent manner. For page load events this isn't an issue as the event object does not contain any valuable information.

Update: I've written the new technique up on my SitePoint blog and incorporated an explanation of closures and how they are used to preserve any previously assigned onload handlers.

Update 28th May 2006: Billy Pan pointed out that the original code caused a runtime error in IE 7. His fix was to add an if (oldonload); I have rolled this fix in to the code shown above.

Tags: addloadevent, closures, javascript, onload, unobtrusive-javascript

Groovy: Closures

2004-04-11T08:01:16+00:00

Groovy: Closures

I’d nearly written Groovy off as a pointless Jython clone, but it actually has some interesting features.

Tags: closures

Closures and continuations

2003-04-03T18:56:07+00:00

Thanks to Dan Sugalski (designer of Parrot, the next generation Perl VM) I finally understand what continuations and closures actually are. He explains them as part of a comparison between the forthcoming Parrot and two popular virtual machines already in existence:

(Perl|python|Ruby) on (.NET|JVM) leads in to the explanation.
The reason for Parrot, part 2 explains closures.
Continuations and VMs explains continuations.
Continuations and VMs, part 2 rounds things off by explaining why the JVM and the CLR are unsuitable environments for supporting these language features.

Tags: closures