5.8. A class is not atomic

A class defines the behaviour of its instances, and the state that they carry in support of that behaviour. You can use this class as-is, or subclass it to provide more specialized behaviour. This is where the story ends with most object oriented programming languages, but not with TOM. In circumstances where you have no control over a class, for instance because it is part of a vendor-supplied library, not being able to amend it to your needs might just mean that you can not use the class or, even worse, the whole library.

TOM classes are not atomic. A class can be modified: you can add methods, instances variables and superclasses, without modification to the original source, which is essential in case you do not have access to it. Modification can take place at compile, link, and run-time. Methods can also be replaced, for example to fix erroneous behaviour of the original implementation.

[A limitation of the current runtime library is that adding instance variables at run time to a class of which instances have been allocated is not possible.]

Suppose the Counter class we have used as an example throughout this chapter is supplied to us without the source code. It doesn't fully suit our needs, but we do not want to waste any effort rewriting it and we have no control over some locations in the code where Counter instances are allocated, making subclassing not an option. We can write an extension of Counter to make it suitable for our purpose.

Suppose the needed extra functionality is a current_value method which returns the current value of the Counter. We can supply this functionality in the following extension:

implementation instance
Counter extension fix

  = current_value;