Concealed Single-Letter Variable Names

While working on some old code of mine I was disappointed to find the following:

theta += omega * duration;
position = new Point(cos(theta), sin(theta));

Theta? Omega? What on earth was I thinking? Those are single-letter variable names. Single greek letter variable names. Spelling them out longhand doesn't change the fact.

I've seen the same pattern in other programs as well. Do we programmers suffer from terminal math envy? Do we think that only by writing unreadable tangles of greek symbols can we demonstrate our intellectual prowess? Even though we use the roman alphabet?

I wouldn't write code like this:

p += u*t + 0.5*a*t*t;

And writing it like this doesn't make it any better:

pea += ewe*tea + 0.5*eh*tea*tea;

This describes what is really being calculated:

position += velocity*duration + 0.5*acceleration*duration*duration;

And the first example is better as:

rotation += angularVelocity * duration;
position = new Point(cos(rotation), sin(rotation));

OOPSLA 2005 Reflections

I've just got back from OOPSLA 2005. It was held in a soulless conference center in San Diego that was, strangely, shared with a couple of quite scary fundamentalist christian groups who publicised their predictions about when Jesus was going to return and sit on the British throne in magazines left around the foyer. It was odd to be surrounded by two groups of people who clung zealously to their strange ideas in the face of incomprehension from the general public. But of course there's more to OOPSLA than Smalltalk and Common LISP.

Maybe it was the sessions I picked, but retrospection seemed to be a common theme at this year's conference. Linda Rising ran a retrospective looking back over the last 20 years of OOPSLA conferences. Grady Booch described his architecture archaeology, digging through past and present systems in a mammoth project to create an engineering handbook of software architecture and with the Computer History Museum to preserve the source code of historically interesting software. He likened his work to that of the victorian gentleman scientists who collected and collated large numbers of specimens that allowed future generations of scientists to create and confirm their theories. Martin Fowler similarly described his career as digging through systems finding the essence of what worked in practice and bringing those ideas to a wider audience. In the Onward! lightning talks Dave Thomas gave an impassioned criticism of our community for failing to learn and pass on fundamental ideas and techniques. Brian Foote spoke of the need for pattern paleontology, recoding patterns that are now fossilised within our programming languages and in a talk entitled "I Have Nothing to Declare But My Genius" he looked back over his experience with object oriented languages, particularly Smalltalk, and why it taught him that static typing is not useful for object-oriented programming.

Even in the Scrapheap Challenge workshop winning solutions used a mixture of the old — Unix-style pipes and filters — and the new — Greasemonkey scripts and REST web calls. But more of that in another article.

Of course, there was a lot of new stuff presented as well. I missed Jonathan Edwards' presentation on Subtext which I was told was the highlight of the conference. Instead I attended the dynamic languages symposium where Marcel Weiher gave an engaging presentation of Higher Order Messaging, which I've been experimenting with recently. His presentation had the amusing effect of needling a Common LISP programmer who proclaimed that "messaging is bunk" but that CLOS did it all years ago anyway. Higher Order Messaging was also discussed at RubyConf, or rather in virtual chat that went on during RubyConf over IRC. Other new stuff included a demo of LINQ. Interesting stuff but I'm not completely convinced by the end result. It seems a bit of a mish mash of object orientation, procedural and functional programming and, unfortunately, the new syntax improvements are limited to queries and not opened up for general use by programmers.

That's all for now. I'll summarise the results of the Scrapheap Challenge workshop soon.

Refactoring Higher Order Messaging

In my experiments with higher order messaging I implemented convenient methods for selecting elements of a collection by queries sent to those elements: "where", "unless" and "having". These are equivalent to various uses of the Enunmerable#select method but, I think, much more readable.

While working on the Ruby code that used higher order messages I found I needed an equivalent to the Enumerable#any? and Enumerable#all? methods, which query if a collection contains any or all elements that match a predicate. Using higher order messages, I wanted to write statements like those below.

if claimants.all_where.retired? then
   ...
end

if claimants.any_having.benefits > 0 then
    ...
end

It was possible to write those higher order messages, of course, but only with a lot of duplicated logic. I got around this by splitting the higher order message objects into two: one object collects of results from individual elements, the other collates those results into a single total. The collector objects are higher order messages that define predicates over elements. They are common between all collators. The collators define whether those predicates are used to select a subset of the collection, or are combined by logical conjunction (all) or logical disjunction (any). Collectors are created by collators, like so

retired = claimants.select.where.retired?

if claimants.any.having.benefits > 0 then
    ...
end

The only problem now was that the select method is already defined by the Enumerable mix-in. I needed a new name. My solution was to change the naming convention of the higher order messages and as a by product allow a more natural, declarative expression of what was being calculated. In the new style, the example above looks like:

retired = claimants.that.are.retired?

if claimants.any.have.benefits > 0 then
    ...
end

Very expressive, but perhaps a little too whimsical. Only time will tell.

With this refactoring, it's very easy to add new collators. The higher order messages are all defined in a base class and new collators can be created in only a few lines of code:

class Collator
  def initialize(receiver)
    @receiver = receiver
  end
  
  def are
    return HOM::Are.new(self)
  end
    
  def are_not
    return HOM::AreNot.new(self)
  end
  
  ...    
end
  
class That < Collator
  def apply(&block)
    return @receiver.select(&block)
  end
end
  
class All < Collator
  def apply(&block)
    return @receiver.all?(&block)
  end
end
  
class Any < Collator
  def apply(&block)
    return @receiver.any?(&block)
  end
end

class Are < HigherOrderMessage
  def method_missing(id, *args)
    return @handler.apply {|e| e.__send__(id,*args)}
  end
end

class AreNot < HigherOrderMessage
  def method_missing(id, *args)
    return @handler.apply {|e| not e.__send__(id,*args)}
  end
end

Well, that's enough higher order messaging. The code is available on RubyForge in the Homer project for anybody who wants to play with it.

Implementing Higher Order Messages in Ruby

A higher order message is a message that takes another message as an "argument". It defines how that message is forwarded on to one or more objects and how the responses are collated and returned to the sender. How is this actually implemented?

Under the hood, a method for the higher order message creates and returns a new object that represents the higher order message. This object can capture any message, forward that message on to all the elements of the collection and collate the results that they return into a result that is passed back the sender of the higher-order message.

In Ruby, messages are captured by defining a method named "method_missing". "Method_missing" is invoked with the name and parameters of a message received by an object when the object has no explicit method for that message. That means, however, that a little more magic is required to implement higher order messages. Classes inherit a lot of methods from the Object class. These must be undefined so that they can be captured by method_missing. This is easy to do by calling undef_method. There are some methods that shouldn't be undefined: method_missing, of course, and fundamental methods that begin and end with double underscores. Here then is the base class for higher order messages:

class HigherOrderMessage
  def HigherOrderMessage.is_vital(method)
    return method =~ /__(.+)__|method_missing/
  end
    
  for method in instance_methods
    undef_method(method) unless is_vital(method)
  end
    
  def initialize(handler)
    @handler = handler
  end
end

I can then easily implement higher order message types by extending the HigherOrderMessage class and defining method_missing.

"Do" sends the captured message to all elements of a collection and returns nil:

class Do < HigherOrderMessage
  def method_missing(id, *args)
    @handler.each {|e| e.__send__(id,*args)}
    return nil
  end
end

"Where" selects elements of a collection for which the captured message returns true:

class Where < HigherOrderMessage
  def method_missing(id, *args)
    return @handler.select {|e| e.__send__(id,*args)}
  end
end

I can then add these higher order messages to all enumerable objects by adding them to the Enumerable mix-in:

class Enumerable
  def do
    return Do.new(self)
  end
  
  def where
    return Where.new(self)
  end
end

And that's it for the basics. I added more classes for the other higher order messages, and had to chain two higher order message objects to support the having predicate, but nothing more complex than that.

Anybody got any ideas about an equivalent in Java?

Update: The code is available on RubyForge in the Homer project for anybody who wants to play with it.

Higher Order Messaging in Ruby

I've recently been experimenting with Higher Order Messaging, a design pattern that can be used for querying and manipulating collections of objects in a purely object-oriented manner.

On the way back from JAOO last week I whipped up an implementation in Ruby and applied it to some of my Ruby code. I was very pleased with the result. Higher Order Messaging transformed laborious code that queried and manipulated objects in collections into succinct statements that clearly expressed the application rules being implemented.

What is a Higher Order Message?

A higher order message is a message that takes another message as an "argument". It defines how that message is forwarded on to one or more objects and how the responses are collated and returned to the sender. They fit well with collections; a single higher order message can perform a query or update of all the objects in a collection.

It's probably easiest to look at an example.

The following code allocates government benefits to claimants. To start, here's the definition of a benefit claimant.

class Claimant
    attr_reader :name
    attr_reader :age
    attr_reader :gender
    attr_reader :benefits

    def initialize(name, age, gender)
        @name = name
        @age = age
	@gender = gender
	@benefits = 0
    end

    def retired?
        @gender == :male && age >= 65 ||
        @gender == :female && age >= 60
    end
    
    def receive_benefit(amount)
        @benefits = @benefits + amount
    end
end

In the following code snippets, the variable claimants contains an array of Claimant objects.

Let's compare different ways of implementing the following business rule: retired claimants receive benefits of £50 a week.

Here's how to implement this rule by explicitly iterating over the list of claimants using Ruby's for statement:

for claimant in claimants
    if claimant.retired? then
        claimant.receive_benefit 50
    end
end

Here's the same rule implemented with higher-order functions — methods that accept a block:

claimants.select {|e| e.retired?}.each {|e| e.receive_benefit 50}

And finally here's the same rule implemented with higher order messages:

claimants.where.retired?.do.receive_benefit 50

I think that the code using higher order messages most succinctly expresses the business rule being executed. It expresses what is being performed and hides the details of how. In comparison, the code with explicit iteration mingles business logic within procedural control flow and the code using blocks has a lot of syntactic noise and additional block parameters.

The higher order messaging version does have messy dots between messages, but unfortunately that's an aspect of Ruby we can't change. At the risk of sounding like a frothing evangelist, I have to admit that the code would be neater in Smalltalk:

claimants where retired do receiveBenefit: 50.

I'd also prefer to use the name "each" instead of "do", but the name "each" has already been grabbed by the Ruby Enumerable mixin.

Anyway...

In the example above there are two higher order messages, where and do. The where message returns an array containing those elements of a collection for which the following message returns true. The do message sends the following message to all elements of a list and returns nil. The clause "claimants.where.retired?" returns a list of claimants that are retired, and that list is then sent "do.receive_benefit 50". Thus, the single line means the same as:

retired_claimants = claimants.where.retired?
retired_claimants.do.receive_benefit 50

Higher order messages provide a convenient framework for querying and manipulating collections of objects that has the additional benefit of clearly expressing domain logic. Thanks to Ruby's open classes, I added the higher order messages to the Enumerable module, automagically defining them for Ruby's built-in arrays and all other enumerable classes.

More Useful Higher Order Messages

I've found the following higher order messages to be useful when working with collections.

Having filters a collection by a predicate applied to the result of a query sent to each element. This actually combines two higher order messages. For example, to give an additional benefit to claimants older than 100:

(claimants.having.age > 100).do.receive_benefit 25

Unless is the opposite of "where"; it returns the list of elements for which a predicate returns false:

working_claimants = claimants.unless.retired?

In_order_of and in_reverse_order_of sort on the value of an attribute:

sorted = claimants.in_reverse_order_of.benefits

Sum calculates the total of an attribute:

total_benefits = claimants.sum.benefits

Extract returns a collection containing the values of an attribute of the elements:

names = claimants.extract.name

Limitations of Higher Order Messages

Of course, there are limitations to what you can do with higher order messages. Most obviously, you can only pass a single message to a higher order message. This means, for example, that unlike the Array#select method, which accepts a block, the higher-order ?where message cannot accept a general logical expression as a predicate to filter the collection. Instead, you must define the predicate as a method of the objects in the collection.

On the other hand, it's impractical to move all the code that manipulates an object into methods of its class. Take, for example, a report of benefits per claimant that is implemented as follows using blocks.

claimants.sort {|c1,c2| c2.benefits <=> c1.benefits}.each do |c|
    puts "#{c.name}\t#{c.benefits}"
end

Implementing that report with higher order messages would require adding a "write_benefit_report_line" method to the Claimant class. This would mix presentation logic with application logic and reduce the cohesion of the Claimant class: not a good design decision.

To avoid this problem, I added a method to Enumerable that returns a collection of adapter objects that wrap the elements of the original collection. To write the benefits report above, I would now write a BenefitsReport class that can report the benefits for one claimant and create a collection of BenefitsReport objects from a collection of Claimants, as follows:

class BenefitsReport
    def initialise(claimant)
        @claimant = claimant
    end
	
    def display
        puts "#{@claimant.name}\t#{@claimant.benefits}\n"
    end
end

claimants.in_reverse_order_of.benefts.as(BenefitsReport).display

But are these really limitations? After using higher order messages for a while I've come to think that they are not. The first limitation encourages you move logic that belongs to an object into that object's implementation instead of in the implementation of methods of other objects. The second limitation encourages you to represent application concepts as objects rather than procedural code. Both limitations have the surprising effect of guiding the code away from a procedural style towards better object-oriented design.

Higher Order Messaging in Other Languages

It's easy to implement Higher Order Messaging in any dynamically typed OO language that can capture unknown messages. It was originally written in Objective C and Smalltalk and I wrote the Ruby implementation in only a couple of hours on the plane. I've described the implementation details in another post. I think this pattern would be most useful in languages that do not have a succinct syntax for higher order functions, such as Python.

I also tried, and failed, to implement higher-order messaging in Java 5 using the java.lang.reflect.Proxy class. If anybody can implement higher-order messaging in Java I'll be very impressed. Please let me know if you do.

Update: I've written a short post about how to implement this in Ruby.

Update: The code is available on RubyForge in the Homer project for anybody who wants to play with it.