|
A SELF `program' consists of live objectsSelf has no edit/run mode. To change an object, you do not retreat to a source file, or even to a class, you just change the object itself. This was a major design aim of the Self system. However, this stance creates a big problem the moment you want to give your work to somebody else. You could give them a snapshot, but how do they combine your work with theirs? There needs to be some way to separate a `program' from a snapshot.For Self, we take the view that the smallest unit which can be usefully communicated to someone else is a set of logically related changes to a Self system that provides the functionality required for a new `application.' How are these changes identified and communicated? We do not want to have every change to every object become part of a new program, as this would be unwieldy, causing unnecessary state to be saved. Instead, the programmer should identify which changes to the system are logically related. A set of logically related changes is called a module. We will shy away from the term `program' as it has many unwanted connotations. The programmer also needs to communicate how these changes should be applied in a new system. For example, suppose an object contains a slot with 1024 in it. Should that value be copied literally? Perhaps it is the result of some computation (such as the width of the current screen) and should be recomputed instead. There simply is not enough information in a Self object to extract a module completely automatically from a snapshot, and the programmer must communicate her intent occasionally.
|