The Object-Oriented Nature of AmigaOS
Is the AmigaOS object-oriented? It was designed before OO became a
buzzword, but I believe that in many ways it is indeed OO, and that it is
as OO as an Operating System should be. I discuss AmigaOS Exec plus the
various parts that work with it, up and including Intuition.
That is, things rather than variables. This is the most fundamental
concept in OO, though it is shared with things not called OO such as Frames
in artificial intelligence. If we look at the data structures in AmigaOS,
then each task, window, menory-chunk, etc. etc. is held as a 'thing' rather
than a (complex) variable. That this is so becomes clearer when we
consider the next characteristic of OO ...
That is, no intrinsic limit. This means that, internally, the data
structures that implement the objects must be held as linked lists or
similar, rather than in tables. This is precisely what AmigaOS did, and
what gives it much of its power and flexibility. Contrast with some OSs,
which hold their OS-elements in arrays. Even though they might appear to
be 'things' or objects, their real status is as complex variables since
they are really parts of arrays. An array of this kind is of fixed size,
and so there is a maximum number - as Windows people used to find!
A true OO system makes it easy to define new classes of object at future
times, as need change. Thus extending the life of the product. In
traditional OO this is achieved by some addition to a class hierarchy, but,
however implemented, the main and most important benefit is this ability of
the software to evolve according to needs. We find exactly that in Classic
AmigaOS. With a few exceptions, AmigaOS has is so designed that new types
of things and new features can be added at a later date - and not just
bolted on, but integrated in a way that is very elegant. We think of
datatypes, boopsi, SANA, etc. This occurs, not because of any cumbersome
class hierarchy (see below) but rather because of its extremely elegant and
appropriate design.
That is, objects can have new attributes added during their life that were
not thought of in the original design. In OO these are often called slots.
Now, original AmigaOS did not have this very easily. Though there was
usually an Expansion pointer and bit in each structure to allow for this,
albeit in a clumsy way However, with the advent of TagItems it does have
this. All one need do is define a new tag.
The activity mechanism defined for traditional OO is message passing. As
opposed to procedure calling etc. AmigaOS has an excellent message passing
activity (though it also has procedure calling where appropriate).
Inherent in the idea of message passing is that objects are active in
parallel. That is, they multitask (if not actually multiprocess). It is
the near-OO internal design of AmigaOS that has enabled it to do its
multitasking so well.
Traditional OO derives attributes of objects by an inheritance mechanism,
by which if the object does not have that attribute then it climbs up the
inheritance tree (class hierarchy) to see if classes above it have the
attribute. Now, AmigaOS exec does not have this. (Or at least not
explicitly: if you want to find for instance the number of colours of a
Window, then you traverse the pointer to its RastPort and then to its
BitMap, or via Screen, and such traversal can be seen as similar to
climbing an inheritance hierarchy; but I do not name it as such.)
However I would argue that an exec should NOT have inheritance. Because
inheritance is, by definition, a huge slow-down. Instead of one memory
access to obtain an attribute value (or a very few) you have an indefinite
number, depending on how long the inheritance tree is. Horses for courses:
inheritance aids the human during knowledge representation and design; it
hinders the efficiency and elegance of an OS. Therefore the fact that
AmigaOS exec lacks inheritance is a plus point rather than a minus.
The above were the original OO concepts. Later concepts include
encapsulation and polymorphism. Encapsulation means that the user or
caller of an object should not know nor be able to access the insides of
that object. The reason for this is to prevent programmers from messing up
the inner workings of objects. Is this appropriate for an OS? Well, there
will be much debate. But I think not. As conceived, encapsulation is a
device aimed at making the process of programming less risky with low-grade
programmers. If programmers were higher grade, more careful, more motivated
to care, then encapsulation would be less important.
Now, I remember some years ago somebody making a comparison between
AmigaOS, MacOS and Windoes, likening them to looking under the bonnet of a
car. In MacOS the bonnet was welded down so you could not look underneath.
In Windoze you lifted up the bonnet and found a complete mess that nobody
could understand. In AmigaOS you open up the bonnet and there is
everything laid out neatly and cleanly. Encapsulation, when taken
religiously, leads to the MacOS syndrome.
Each objects 'knows' how to respond to each message it receives. It is the
object's responsibility to know this, not the caller's. In AmigaOS exec we
find polymorphism in some places and not others. It is there in the
message lists in that it is the responsbility of the receiver of the
message to know how to deal with it. But it is not there in e.g. memory
lists. However I would argue that it probably should *not* be there in
memory lists because of the need for speed. Any attempt to check the type
incurs a runtime penalty. Maybe AmigaOS could use a bit more polymorphism
in some places (e.g. Intuition gadgets can have either a bitmap or a list
of lines, but not a mixture - that is a pain.)
Therefore, I contend that AmigaOS exec is almost exactly as OO as an OS
should be. That is, indeed, one reason I have delighted in it for so long,
and it has seldom disappointed me.
Copyright (c) Andrew Basden 1998.