There had been a number of suggestions for improvement to Alan v2. Some of them focused on details or missing features, or even mis-features, in either the language or the interpreter. Some suggestions addressed the (percieved ;-) lack of flexibility and power of Alan.

Personally I had been thinking on how to implement, what I thought to be a road to more flexibility, object orientation.

First we have to clear out what object orientation really is. In the new manual there is a section about the concept, so here I just state that in my view object orientation is about inheritance, specialisation and polymorphism. ;-)

This allows a user to create classes, templates, that keeps, inherits, properties from its parents, adds to them and override others. From them instances can be created. But the neat thing about object orientation is really the polymorphism. Polymorphism literally means "of many forms". An example (from the programming language field) is that if a placeholder, such as a parameter declaration, specifies that it will accept one class, it will, during run-time, also accept an instance of any of the sub-classes of that class. It might also act differently, depending on the properties of that sub-class. Of course, it must be guaranteed that sub-classes always keep the properties of its parents, or at least its important aspects.

So, to introduce object orientation in Alan, I first had to figure out what the properties of the Alan classes and instances where, and how these should be inherited to create the polymorphism.

To imitate the locations, objects etc. Alan V3 needed to allow all properties of all those types. So the properties of Alan V3 is the union of all the existing Alan v2 properties. A number of predefined classes was required to mimic the Alan v2 types. It was also necessary to flesh out which properties would be required for which pre-defined class and the semantics for those classes. For example, the pre-defined class "location" would allow creation of instances similar to Alan v2 LOCATIONs. That would require that all "locations" inherited the (built-in) possibilities to locate things and actors there, to have exits, but not scripts, etc. So a set of semantic rules was also devised for each pre-defined class.

Implementation of a programming language is rather straight forward and predictable once you have the language design. However it is also a major undertaking, so starting from scratch really put me off for a number of years.

Working with programmers and helping them become more efficient, I read a lot on various subjects and came across Refactoring: Improving the Design of Existing Code by Martin Fowler. It shows in much detail how to, using minute steps, keep changing code while constantly keeping it in good health. The idea is that, by constantly transforming your code in small steps, you can make the code suitable for a particular addition, e.g. a new feature. (This is in contrast with "traditional" approach when you add the feature, and then try to fix it, which doesn't happen, leading to code degradation). To do this with confidence, you need a lot of tests; tests that test on a very low level, e.g. that a particular result is returned from a subroutine if you send it a specified set of inputs. You run these tests for every little change you do, making it obvious what you changed when things stopped working. The approach originally was geared towards object oriented programming, but it inspired me a lot, even in daily life, and I decided to use this approach to continue developing Alan from the existing code base (which is in plain C).

This have proved a success, because during the last year, 20+ development previews have been released. Each with new features, more test cases, and possibility to test, and get feedback to, the new features. This is an ongoing process and will continue even after Alan v3 is released.