Say I have an object that likes to transition solely between happy states every time a certain event occurs. Here’s how I might handle it:

 theObject.happy = !theObject.happy;

There. Simple huh? Something you probably learn how to do in an introductory programming course. It might be surprising to you, but someone asked a question on how to do this on Stack Overflow. The other alternative provided in the answer is the somewhat more cerebral:

theObject.happy ^= true;

Thanks Spock. Of course if your language doesn’t have an assigning XOR operator this option is ruled out. If you value clarity of code, or you simply don’t want less brainy maintainers pestering you about what your code is doing, you rule this option out as well.

So I’ve been writing a lot of code recently of the first form, and it’s been making me sad. There’s a strong feeling of non object oriented-ness about it. I mean, to toggle the state of an object I have to:

1. ask it what its current state is;
2. flip that state locally;
3. and then tell the object to take on this new state.

Bleh! Why the hell should I care what state it currently is in? I just want to toggle it! Shouldn’t I just be able to ask the object to toggle it’s own state; perhaps of even multiple properties in a batch sequence?

Naturally, nobody wants to write a toggling method for every writable boolean property of their objects. So either there needs to be automatic support in the platform or some ability to provide a general toggling abstraction.

One such example of a crude toggling abstraction would be a Ruby module defined like the following.

module Toggler
 
  class ToggleHelper
 
    def initialize(target)
      @target = target
    end
 
    def method_missing(sym)
      @target.toggle(sym)
    end
 
    def toggle; end
 
  end
 
  def toggle(*sym)
    return ToggleHelper.new(self) if sym.empty?
 
    self.send("#{sym}=", !self.send(sym))
  end
 
end

Such a module could be mixed-in at the appropriate levels of an inheritance hierarchy, or maybe even at the root level if you’re game.

With the mix-in mixed-in, toggling code would be more concise and less repetitious:

the_object.toggle.happy
the_object.toggle(:happy)
the_object.toggle(:wanted, :happy, :virtuous)

Doesn’t a declarative syntax such as this feel much more happy?

Today Yahuda Katz posted his 10 favourite things about the ruby language. His list certainly reflects most of the things I find very appealing about the language. The sixth item highlights Ruby’s excellent support for blocks and lambdas and an argument is mounted that when performing file operations in languages without them, programmers are forced to use an inline “ensure” block every in the same lexical scope that they originally opened the file in, to ensure that the resource is closed. As is often the case the comparison is made to Java, but as any seasoned Java developer will tell you (and this point has probably be made many, many times) it just isn’t true. Java supports a safer and comparable idiom via the anonymous inner class.

The example given is a very succinct Ruby method to print out the lines of a text file. Ruby’s File.open ensures the file is properly closed after the block has completed, normally or otherwise:

def run(input)
  File.open(input, "r") do |f|
    f.each_line {|line| puts line }
  end
end

The Java version listed does the same but, predictably, is far more verbose and laborious:

static void run(String in) 
throws FileNotFoundException {
  File input = new File(in);
  String line; Scanner reader = null;
  try {
    reader = new Scanner(input);
    while(reader.hasNextLine()) {
      System.out.println(reader.nextLine());
    }
  } finally { reader.close(); }
}

However no Java developer that values their sanity is ever going to sprinkle this pattern through their code base any time they want to use a File and ensure that it is closed properly. Here’s what they are going to use instead:

public interface Processor<T> {
  void process(T target);
}

import java.io.*;
import java.util.Scanner;
 
public class FileSlurper {
 
  public static void slurp(String fileName, Processor<Scanner> processor) 
    throws FileNotFoundException {
 
    File input = new File(fileName);
    Scanner reader = null;
    try {
      reader = new Scanner(input);
      processor.process(reader);
    }
    finally {
      reader.close();
    }
  }
 
}

Once that infrastructure is in place, the Java implementation of the example becomes:

FileSlurper.slurp(input, new Processor<Scanner>() {
  public void process(Scanner reader) {
    while(reader.hasNextLine())
      System.out.println(reader.nextLine());
  }
});

No one can argue that this is as pretty or convenient as the Ruby version, but it does ensure that file opening and closing is handled correctly without any effort from the client code. The code in the anonymous inner class can even access variables in the current lexical context, as with the Ruby block, with the caveat that they must be declared final (not quite a lexical closure!). This pattern, in conjunction with the Processor interface may be used any time there is a need for similar resource acquisition and clean–up procedures, as might be the case for locks or database connections.

Lambdas and blocks are very useful constructs, and the anonymous inner class can act as an acceptable, if far from ideal, analogue. What an anonymous inner class can’t do is act as a co–routine; this is a truly powerful feature of Ruby’s blocks and associated method invocation features that Java can’t directly compete with.

One thing’s for certain: the Ruby community won’t win over Java developers by giving examples of deficiencies where none exist.

That got me thinking about the solution in Scheme, a language I find very appealing, and Haskell, which I had started picking up a few months ago but had to abandon due to lack of time. Even so I managed to remember enough to get this basic solution within a few minutes:

wondrous :: Int -> [Int]
wondrous 1 = [1]
wondrous x
	| even x = x : wondrous (x `div` 2)
	| otherwise = x : wondrous (3*x+1)

Here is the most obvious implementation in Scheme:

(define wondrous
  (lambda (x)
    (cond
      ((= x 1) ‘(1))
      ((= (modulo x 2) 0) (cons x (wondrous (quotient x 2))))
      (else (cons x (wondrous (+ (* 3 x) 1))))
    )
  )
)

As you can see both of these functional languages are really suited to expressing such algorithms, particularly Haskell with its excellent pattern matching expressions. I have no doubts that there are far more elegant solutions in both languages; I’ll post them if I get suitably inspired.