Philosophy I found this on the interwebs and wanted to catch it here for future reference.

Object Calisthenics

In addition to East Oriented Design I also promote following the Object Calisthenics approach.

William Durand’s write up: Object Calisthenics
Java World’s write up: Object Calisthenics

Object Calisthencis is about changing the way you code as is East Oriented Design.


9 steps to better software design today, by Jeff Bay:

Only One Level Of Indentation Per Method
Don’t Use The ELSE Keyword
Wrap All Primitives And Strings
First Class Collections
One Dot Per Line
Don’t Abbreviate
Keep All Entities Small
No Classes With More Than Two Instance Variables
No Getters/Setters/Properties

Old Blog

This is my new blog hosted by github pages and I’m using Jekyll etc.

All the old posts will be re-done and returned here as soon as I have time to move them.

If there is a particular post you are after then let me know and I’ll try to move that over first.

Redline Smalltalk

Redline Smalltalk Mascot

As some of you will know I have been implementing a Smalltalk compiler for the Java Virtual Machine. You can find more details here and the source here.

After some time away doing other things I have come back to Redline Smalltalk with gusto. The latest code is a total re-write as I’m now using a PEG based grammar via ANTLR4 where previously I had used ANTLR3 which was not as good at handling Smalltalk syntax. The result is a smaller and faster grammar.

Another major change is that everything is more message based, that is instead of generating a Java Class in memory that represents the Smalltalk class and instantiating it the Java Class that is generated simply sends messages to Smalltalk Objects to achieve the same result. The way Smalltalk was intended.

The compiler is almost complete and you can run Smalltalk today. Here is an example ‘Hello World’.

And here is a snippet from the source for the base Object in the Smalltalk Runtime Hierarchy:

All Smalltalk sources are loaded through the SmalltalkClassLoader which generates an in memory Java Class and instantiates it which causes the messages contained within the class to be sent. Given a Java Class is generated it is possible to integrate with Java Libraries and for Java to call code in Smalltalk.

You will notice in the snippet above that some messages are being sent to the Object ‘JVM’. This is a special Object that allows Redline to generate any JVM bytecode instruction thereby allowing any code you can create with the JVM to be implemented. You can think of messages to JVM as the equivalent to inline assembler in C/C++.

You can also package up Smalltalk into a STAR (A Java Archive but with a snappier name) and deploy to Amazon AWS Lambda which is a benefit of targetting the JVM.

Work continues on Redline Smalltalk and I welcome people to get involved. You don’t need to know Java although there is also work to be done for people who do. If you would like to be involved please email me at object at

East Collections

This post is about implementing a Collection using an East Oriented approach.

A Recap

There are a two simple rules to greatly improve your code and these are collectively called an East Oriented approach. These rules are:

  1. Public methods must be void (no return value) or return this (self). Preferably void (no return value).
  2. An exception to rule #1 is where the method is a Factory Method that returns a new instance of a Class.

Some have referred to this style as a “Continuation” or “Functional” style. I’m a Smalltalker so it was going to happen.


Consider the need to see if a given Collection of Permissions contains another Collection of Permissions. This is how it would be written using an East Oriented approach:

The following code is contained in one file to make it easy for you to run as a working example, however in a real project each Class or Interface would be in its own file and not static. Additional notes follow the code gist.


A native Collection is not used because you cannot define only the behaviour you want on a native Collection, and because if the internal collection (line 28) changes you don’t want to have to change all the code that depends on the Collection.

The Collection (the thing with the information) is asked to do the work = The Tell Don’t Ask Principle.

As the caller / implementor of ContainedListener you can do whatever you want without modifying the Collection code. In this example I simply print the contained items. Your implementations of ContainedListener will also serve as a definition of what happens with contained items rather than that logic being spread throughout the codebase.

To fit in with other ecosystems or frameworks there are some methods that don’t adhere to an East Oriented approach like “toString” and “equals”. These are usually kept to a minimum.

Making this Collection Class generic would not be hard but it is not made generic here so as to be more clear for the reader and immediately runnable.

The “equals” method of Permission is an example and doesn’t adhere to Java conventions for an equals method.

I have found through following an East Oriented approach that I write less code / tests, clearer code / tests and my logic finds a Class where it belongs rather than being spread across the codebase.

Your milage may vary