July 24, 2006

Closures for refactoring

Comments about my previous article reminded me (in an indirect sort of way) of another "programming in the small" thing - using closures for refactoring.

Closures - good for collections

Fans of languages with closures often show collection processing sorts of things - like most of the examples in one of Martin Fowler's articles that I showed python translations for, and python's alternative to this sort of thing - called "list comprehensions".
However, closures also allow for some neat refactorings independent of anything to do with collections.

Duplication that looks difficult to get rid of

Let's say you've been working with David and Ade and you've produced the definitive way of reading a byte from a file. Later you find you need to read a UTF encoded string from a file. You use the same "pattern" (in a loose sense of the word) in both cases.

You don't want to have to keep repeating this every time you want to do something similar, but slightly different. How do you refactor the similarities between these methods? The fact is that in Java I see lots of this sort of duplication - because in Java, getting rid of this sort of duplication is often verbose and clunky. However, it is possible, and sometimes very worthwhile.

Using closures to get rid of the duplication

Java provides a way to define some sort of closures - using anonymous inner classes. Here's how you could remove the duplication in this example. It's quite painful. My fingers hurt as I typed the code. Then I got a headache.

... and in Python

In languages with better support for closures (or at least support for passing functions around), it can look a whole lot better.
A direct translation of the original code in Python (taking the liberty of defining a class DataInputStream) would be:

which hurts much less than the Java version (but slightly more than the Smalltalk version would - but that's another story). [Martin Fowler shows in his article how a Ruby caller of similar code would look "File.open(filename) {|f| doSomethingWithFile(f)}".]
Python doesn't have great syntax for defining closures - it would be nice to be able to define the two "execute" functions anonymously. You can do this for one of the methods using "lambda" but not the other because of the limitations of "lambda". In Smalltalk or Ruby the syntax for this is better. Here's the "lambda" version of the "readByteFromFile" function.

I'll tell you what I want, what I really, really want, because David wants to know.

I'd like Java to have better support for closures. I'm impressed with C#'s anonymous delegates, although, it's still not as good as Smalltalk.
I'd also like developers to put more effort into reducing duplication, even when the language gets in the way.
Posted by ivan at July 24, 2006 9:09 PM

Copyright (c) 2004-2008 Ivan Moore

Comments

In Groovy this kind of refactoring becomes less painful on the fingers, and yet still runs entirely within the Java platform.