Book Contents Previous Chapter Next Chapter
This chapter provides a brief overview of some fundamental Magic Cap concepts, including objects, classes, and operations. This overview is suitable for all Magic Cap programmers.
You should read this chapter as you start programming for Magic Cap. You will likely find that you don't remember everything in this chapter on first reading. Later, as you read the rest of this book and begin programming, you can refer back here for fundamental definitions and information.
Magic Cap provides an environment for supporting persistent objects. An object consists of a structure that includes data elements and a set of actions that operate on the data. Each object provides interfaces to its actions via operations and to its data elements via attributes. Internally, objects specify functions that implement operations and storage locations that implement attributes. These internal functions are called methods and the storage locations are called fields.
Objects are described by templates called classes. Each class is defined in terms of its difference from another class, called its superclass. Each class inherits operations and attributes from its superclasses, and the new class can redefine any operation to enhance or change its behavior. All classes that define objects ultimately descend from class Object.
When you call an operation, the method that executes in response to the call is defined by that object's class or by one of its superclasses. When an operation is called, Magic Cap selects the method to run by examining the object's class and, if necessary, its superclasses. The object that has its operation called is the responder.
Magic Cap includes several major sets of features, such as the datebook, notebook and name card file, that provide services usually handled by application programs on conventional computer systems. In addition to its built-in features, Magic Cap acts as a platform for additional features to be added. When you program in Magic Cap, you make software packages, collections of objects that perform functions and provide features for Magic Cap users. Software packages are often called simply packages.
Whenever you deliver any Magic Cap software to users, you'll provide a software package.
Personal communicators based on Magic Cap are designed to keep permanent user data primarily in RAM rather than on an external storage device such as a hard disk. This RAM is called persistent memory because it retains its contents whether main power is turned on or off, as long as some power source is applied (main battery, backup battery, or AC power). Persistent memory is useful for permanent user data, such as electronic mail messages, name cards, appointments, and so on.
Magic Cap defines another kind of RAM that does not retain its contents when power shuts off. This kind of memory, called transient memory, is useful for objects that are created and destroyed within the scope of an executing function, objects that can be recreated from persistent data, and other temporary objects. When you create new objects, you can specify whether they should exist in persistent or transient memory. If you create an object in transient memory, your package must be prepared to recreate it if main power shuts off.
All Magic Cap objects in memory, whether in main RAM, ROM, or on a PCMCIA card, are collected into groups called clusters. A cluster is associated with a contiguous area in memory and manages all the objects in that area. Each object belongs to exactly one cluster. Like most structures in Magic Cap, clusters are themselves objects. Each cluster in RAM controls only one kind of memory, either persistent or transient.
Every package defines a set of clusters in which it can address objects directly. This set of clusters is a context.
Every object in Magic Cap can be addressed at runtime with a 32-bit value called an object ID. You use an object's ID when you call one of its operations, get access to its fields, or pass it as a parameter. When you use an object ID, Magic Cap's object runtime quickly and efficiently converts the object ID into a pointer to the object.
When you define objects at build time, you don't use object IDs. Instead, you use instance definition IDs, values that are automatically converted to object IDs when the package is built.
Your package can use an object ID to address any object created by the package itself or any object in a system cluster. You will typically see object IDs as hexadecimal numbers displayed by debugging tools.
Magic Cap has a collection of well-known objects that you can address at build time and at runtime via special object IDs called system indexicals. Magic Cap defines indexicals for hundreds of different system objects, such as images, windows, object lists, scenes, and many more kinds of objects. You can create package indexicals that define key objects in your own package.
Magic Cap keeps track of its system indexicals in an object list called the system root list. Similarly, each package maintains a package root list to hold its indexicals.
In addition to its fields, every object can have one variable-length area, called its extra data. The extra data can be any information that can change its length at runtime. For example, Magic Cap defines many classes that include lists of object IDs. These lists are usually kept in the objects' extra data, because the size of the extra data can vary as the list adds or removes members.
Because every object has only one extra data area, only one class in an object's class ancestry can use extra data. Once a class defines an extra data area, no subclass of that class can define another extra data area for its objects.
For comprehensive information about the topics described in this chapter, see this book's Object Runtime and Software Packages chapters.
Book Contents Previous Chapter Next Chapter