To function as an object-oriented operating system, PenPoint has a number of fundamental capabilities that traditional operating systems do not provide.
Among these are
• user-controlled installation/deinstallation of classes, including sharing of classes between applications and message sending across process boundaries
• versioning support so that new releases of application and system code can work correctly with objects created by earlier versions
• support for objects that are global to the system and therefore shareable between the system and applications
• means for protecting the operating system from being damaged as a result of the subclassing that is an inherent part of object-oriented programming
• support for prohibited or controlled access to objects that are either private or protected (for example, operating system file objects that must be pro-tected)
• unique IDs for all objects in the environment so that message passing can be handled efficiently and correctly, even when data objects are transferred from one PenPoint machine to another (which means that PenPoint objects are persistent)
We will examine many of these facilities in this chapter, though many will be dealt with in greater detail later in the book.
By providing these capabilities, PenPoint brings object-oriented technology right to the foundation level of the operating system, enabling everything that happens in a PenPoint-based system to have all the intuitiveness, efficiency, ease of learning, and other characteristics of good object-oriented systems.
PenPoint's solution is to provide a subsystem called Class Manager. You will interact a great deal with this subsystem and its important messages as you create PenPoint applications. The Class Manager is an integral part of the PenPoint kernel (see Chapter 4 for other elements that share the PenPoint kernel with the Class Manager). Because the Class Manager is part of the kernel, all the rest of PenPoint can use the Class Manager; this permits those other elements of the system to package their functionality as classes. When-ever you build a PenPoint application, two of your main tasks will be to define new classes and create new objects. This process involves the Class Manager interaction.
In PenPoint, classes are used to package all public APls. You can think of this as a way to describe and encapsulate highly flexible code modules.
However, these code modules typically use traditional C code with function calls and pointers to implement their public APls. The result is a system that combines the efficiency of C in its internal implementation with the power of object-oriented programming in its external programmatic interface.
The Class Manager
Programming Efficiencies
Message handling does not require any special language constructs. A message is constructed with standard C function calls, except that message arguments must be stored in data structures before making the C function calls. The resulting C code looks a little unusual but this implementation style is efficient and implementable in ANSI C.
Object creation in PenPoint is also straightforward. Typically, you send the message msgNew to a class you wish to instantiate. For example, to create a new list object, you would send msgNew to clsList. You must always precede msgNew with msgNewDefaults to initialize a data structure to default values before you override some or all of those default values and then send msgNew. In either case, the process is simple and standard.
Un iq ue Identifiers
PenPoint uses 32-bit unique identifiers (UIDs) to help the system keep track of all classes and objects. A UID encodes information indicating whether the object it references is global or local, and well-known (that is, permanently defined at compile time) or dynamic (that is, created by the Class Manager at runtime). Global well-known UIDs are assigned and administered by GO Corporation to avoid conflicts. Because applications can embed other appli-cations (see Chapter 8), it is important that any well-known UIO you plan to use in your program be assigned by GO Corporation and therefore guaran-teed to be unique among assigned UIDs.
PenPoint also supports the use of UIDs within filed data. These UIDs must be persistent (that is, unique across all time and space). PenPoint accom-plishes this with Universal UIDs (UUIDs), which are 64-bit quantities that include a unique machine 10 from the hardware on which PenPoint is running.
UUIDs can be used to point to PenPoint objects even when they've been filed to external media and then loaded back into PenPoint, regardless of which machine they are loaded into.
PenPoint has two root classes in its class hierarchy. All objects descend from clsObject, but classes additionally descend from clsClass. Note that clsClass is a meta-class, so that for each class in the system there is a corre-sponding object that stores information about the class as a whole (including the code that implements its methods) and implements class-level operations.
In an idealized sense, objects encapsulate data and behavior (with behavior, of course, expressed as code). But you obviously would not want to duplicate the code with every object instance. To avoid this, clsClass supports classes as a special kind of object that provides the shared behavior (code) and information for a type, or class, of objects.
The Class Manager