Closures
There has been a lot of chatter about the
closures
proposal penned by Neal Gafter. And, in particular, whether or
not I support it. I absolutely do. My "Feel of Java" talk of many
years ago got rather infamously twisted at JavaPolis a couple of
months ago. Java feels alive, not stuck in some chisel marks on
stone tablets. Closures were left out of Java initially more
because of time pressures than anything else. Closures, as a
concept, are tried and true - well past the days of being PhD
topics. The arguments are in the details, not the broad concepts.
In the early days of Java the lack of closures was pretty painful,
and so inner classes were born: an uncomfortable compromise that
attempted to avoid a number of hard issues. But as is normal in so
many design issues, the simplifications didn't really solve any
problems, they just moved them. We should have gone all the way
back then. Some have criticized the current proposal as being too
complex. If you read through all of what Neal has written, you'll
see that there are two sources of this perception: the spec is
really detailed and explores all kinds of corner cases that never
get touched on in most programming manuals; and the proposal is a
collection of features that at first blush seem separate, but in
fact are deeply inter-related and push each other into existence.
