| persist | | reflect | | selfdiff | | selfuse | | gmodel | | gui |
back to:
An example of static reflection in a C program is the sizeof command. It allows the application to see some data structure as a certain amount of bytes. We could have dynamic reflection using the operating system's commands to change the execution priority or, perhaps, by obtaining a pointer to the stack and walking up the call chain to change something.
Every operating system is necessarily reflective, but we will call it a reflective OS only if it is designed to support reflection in an organized manner. This is much easier to do if the whole system is structured as a collection of objects.
We usually have three relations between objects: contains, inheritsFrom and isKindOf. In a classless model ( such as in the Self language ) the isKindOf relation is no longer needed. If we represent system resources ( such as memory, CPU time, disk space, etc... ) as objects too, how are these related to the objects they support? We will call these system objects meta objects and add the relation isSupportedBy. Of course, these meta-objects are themselves objects and are supported by other meta-objects. In the Merlin system this chain ends in the core object, which isn't supported by anybody.
While Merlin's reflective architecture is described elsewhere, it is interesting to compare this approach to traditional implementations of Smalltalk and Self. These divide the system into the "virtual machine" and the "virtual image". The image is simply the collection of all objects. the virtual machine ( VM ) is a big black box the actually makes the objects work. In our terminology, every object isSupportedBy the VM by definition. Though some reflection occurs using normal ( almost ) objects like activations and classes ( or mirrors, in Self ), most of the interaction with the big meta-object VM happens through a set of primitive methods. Note that the VM may be implemented in a very object oriented way ( say, in C++ ), but it never seems that way from the application programmer's point of view.
The Self Reference Manual warns that reflection is very bad for portability. This is true: the implementations just described can change the details of the VM as much as they want with little fear of breaking user code. The advantage of the approach chosen for Merlin is that more of it ( the compiler and garbage collection, for example ) can be written in Self.