Joshua wrote:
> Bookmarked, ’cause I want to know how you use array to get closures in Java (come back, Foo, come back!). Not that I actually write in Java hardly ever, but still.

Answer: Java’s anonymous functions are *almost* closures. Specifically, when you build an anonymous function within a block, it’s closed to all final local variables declared in that block or in an outer block.

The problem is that those variables *must* be final. Why? Who knows? There’s no performance hit unless you actually use a non-final variable, and even that’s not a very big hit. But Sun sought to screw us over I guess.

Well, almost. The array trick is as follows. Let’s say I wanted to make an accumulator generator (Paul Graham style, albeit with methods). I can do this:

interface NextInt { public int next(); }

public void makeNextInt(int init)
{
final int[] count = { init };
return new NextInt() { public int next() { return ++count[0]; }
}

Note that the NextInt class uses an outer lexical variable (count), and thus that variable must be final. But it doesn’t mean you can’t change it — it just has to be composite. Instead of having it be an int, make it be an int[1]. That’s the array trick.

Of course, you can make a MutableInteger or whatever if you want, and that’s a little faster as it doesn’t require an array bounds check, but it’s more work to write. It’s not part of the syntax of the language like the array is.

It turns out that there was a strong counterproposal to the crap being put out right now for excessively complex closure semantics. The counterproposal just does a simple semantic wrapper around exactly this idea. Let’s hope the Java folks get a clue and adopt it.

RenoX asked:

> Well Foo as the author has shown, D has anonymous function so you can use them for GUIs, are closure really necessary for GUIs?

Closures are hardly a necessary feature. But they are an *enormously* valuable feature for GUIs, threading, event management, and exception handling. Because they make doing callbacks elegant. Having anonymous functions without having closures based on lack of “need” is like saying you can do everything in recursion, so why bother with including for-loops…

Alex

FeepingCreature: Three interesting ways to fake closures, thanks for the tip.

Daniel: Your stack-copying writeup is really cool, I had no idea it could be that simple.

Joshua: You have several good points in your comments (and no bad ones ).

To be honest, it’s fairly rare that I come across a case where I miss being able to just directly return an inner function; and in cases where I want to do so, D has a few ways of working around that (both the hack in my post above, and also ones involving constructs like bind).