OOPC is a full source code software development toolkit. OOPC has two components: an object system that turns standard C into a dynamic object-oriented programming language, and an application development framework to accelerate application development. This article tells why OOPC was created (its design goals), and in doing so provides a description of OOPC's feature set.
The Macintosh version of OOPC has been shipping since August, 1992, and is currently at version 1.3. A Windows version is going to be available before the end of 1993. OOPC's API (application programming interface) is already platform-independent.
There is a common myth that an object system requires compiler support. Most object systems are implemented using a new language (such as Dylan), or an extension to an existing language (CLOS, C++), which require a new compiler (or at least a preprocessor), but this results from a design decision to create or modify existing language syntax, or simply to implement the object system using a compiler. People who design object systems are often computer language junkies and compiler writers; people who are biased to think in terms of "advances" in syntax, which require a new compiler. C++ is a perfect example of such tinkering. OOPC fully implements dynamic object-oriented programming without requiring special preprocessing or compiler implementation.
There is a trend in object-oriented programming products towards flashy development environments, with slinky linkers that slip patch code in without having to quit running an application in a debugging session, or other frilly features that "give great demo." That was never on the goal agenda for OOPC. OOPC is a simple-but-sophisticated, meat-and-potatoes code library. OOPC works with any C compiler. This approach keeps Electron Mining's development efforts focused on providing leverage for its customers, to accelerate their application development, not on spinning marketing flash (or trying to rope people into a proprietary development environment).
Most advanced object systems take their inspiration from CLOS, as does OOPC. CLOS provides dynamic definition of class-objects, and the use of generic functions to enforce a simple API.
OOPC uses verb functions, which are the same concept as CLOS's generic functions. (The term verb is used to emphasize the concept of verb-object action. Generic seemed too nondescriptive.) Any object is drawn using draw, or acted upon using act. Different verbs may dispatch to the same method. Often, the same method is used to draw or print an object; only a few classes have objects that print differently than they draw. Thus, using verb functions both simplifies the API and makes it consistent, and provides a means for greater code reuse while doing so. The verb set is extensible.
Before-methods and after-methods provide dispatch control, minimize dispatch overhead (by dispatching to two methods in a single call), and maximize code reuse (by allowing selective method overriding). OOPC also implements the concept of middle-methods, where dispatch can continue from inside a method (using continue_dispatch). Dispatch can also be targeted to a specific method (using dispatch_to).
OOPC dispatch is table driven, making it very fast. A verb is actually an index into a method table, masquerading as a function call. Methods can be defined or changed any time during program execution. Dynamic definition allows all aspects of object orientation to be defined and modified at run-time. The effect on flexibility with regard to design and implementation is profound.
A simple example of dynamic inheritance: while reading in a dialog item resource for a file, create dialog item objects, then add the right class (control, picture, text, and so on) to a dialog item once the item type is discovered (by reading the dialog item resource data). This can be done in a static OOP language by not assigning the dialog item type class before reading the dialog item resource definition, but that involves processing in a way dictated by the language's limitations, rather than doing things the way that might first come to mind (which is usually the most straight-forward way) if no constraints were imposed. The flexibility of a dynamic object system brings both small and large benefits.
Object orientation with OOPC is achieved using a small set of functions. new_class is used to create a class. new_object creates an object. define_method associates a verb function with a specific method. set_method_flag sets a before- or after-method status for a method.
OOPC implements the concept of agents. An agent is a subsystem of processing. There are agents for overall application processing (startup, quit), events handling, printing (page setup, print job, printing), cursor control, and menu/menu item enabling/disabling. An agent is associated with a class, but provides a mechanism to encapsulate processing and allow processing modification, much as a class encapsulates object data and behavior.
OOPC's object system has built-in support of object linkage. Objects can be linked to one another. This has two purposes. First, in a software world of self-contained modularity, object links are essential for object interaction. A tear-off menu, for example, is a cooperative effort between a menu, a window actor, a view, one or more lists, and a picture of the view (for rapid drawing of the view for the menu). Having an object system that has object linkage support built in facilitates setting up component software interaction. Second, object links are used for garbage collection; specifically, to make sure an object isn't freed if any other objects are using it.
Maintaining collections is an essential aspect of object-oriented programming. A document is a collection of pages. A view is a collection of objects that appear in the view. A menu bar is a collection of menus, each of which is a collection of menu items. The OOPC object system has efficient functions for maintaining collections.
The architecture of the OOPC class library revolves around actors. A document is a type of actor, as are dialogs. Actors are at the top of the activity hierarchy. Actors handle window events, because actor objects own window objects.
What happens when a user clicks on an object within the content region of a window? The EventAgent tells the actor that an event has occurred in the window owned by it. The EventAgent calls the actor to act. The actor looks to its window, which holds the window's view(s). A view holds a collection of objects that are visible in the window. Windows have at least one view. The actor looks through the objects in its view(s) until it finds the object sitting where the mouse was clicked, then calls that object to act upon itself.
An actor manages its window and the objects that appear in the window. Visually, an actor controls window display. A window draws the views in itself. Each view draws the objects in itself. A document uses the concept of pages. Each page manages display of its own view in the document window. A document manages pages, and adds a new object to itself by adding it to its current page.
MacApp, which is view-happy, requires that every object in a view belongs to a view subclass. OOPC suffers no such architectural nonsense. An OOPC view is simply a container for a collection of objects that has its own coordinate system. Views can be selected for onscreen or offscreen drawing (if the view has an offscreen bitmap).
OOPC 1.3 has three document classes, all of which handle multiple-page documents. cDocument handles documents where the pages appear one after another vertically, as with a word processor. cPoster provides a large, poster-sized document, such as those used in drawing programs. cRecordDoc implements the database record model, where only one page/record is visible at a time. There is also a list actor class that can be put into use for spreadsheet documents. Acting, drawing, printing, undo and scrap operations are handled automatically.
OOPC's class library provides a full set of user interface features. In addition to the classes you would expect, tear-off menus, floating windows, tool, pattern and color palette classes are also provided. All modal dialogs are automatically movable modals, even under System 6. User interaction with standard dialog item types (controls, editable text) is handled automatically. OOPC provides a MultiFinder/System 7 type DA menu bar for any user running under the System 6 Finder.
OOPC controls are platform-independent. New control types can be easily implemented, requiring only a draw method override for simple controls, and an act method for more complex control types.
There is a rule class, used for activity control, and appropriate for building rule-based systems. Cursor and menu activation are controlled using rule objects. Rules can be merged using AND or OR joins to build a rule framework object.
OOPC has a sophisticated multiple-priority event processing agent. There are multiple event queues, each at a different priority. The OS event queue is a mid-priority queue. Handling for any type of operating system event can be modified with a single call to an EventAgent modifier. There is a timer event queue for periodic events. The number of event queues is extensible (by adding one or more constant definitions in the event header file). Threaded processing is accomplished by creating new events of the needed priority. Events can be controlled in any event queue, including operating system events.
OOPC has its own pointer-based memory management system. Figure 1 shows the results of timing studies on Mac OS and OOPC memory management. Large blocks are taken from the operating system and cut into smaller slices, which are for object-related data storage. The Jan/Feb 93 FrameWorks has an article detailing OOPC memory management.
OOPC has a simple exception handling mechanism that is used throughout the class library. Normal execution code is placed between CODE and HANDLER macro statements. Exception handling code, which cleans up by deallocating memory allocated during normal execution (and optionally sets an alert message), is located between HANDLER and CONTINUE_HANDLER statements. (CODE {normal execution code} HANDLER {exception handling code} CONTINUE_HANDLER). CONTINUE_HANDLER sends program execution up the stack frame to the calling method, so clean-up can occur through the call chain. END_HANDLER, which can be used instead of CONTINUE_HANDLER, terminates the jumping up the stack frame (thereby terminating the exception handling process). Exception handlers can be nested.
Error reporting is automatic. A variety of error reporting alerts are provided. The application agent reports errors during initialization, and the event agent reports errors while handling events. (The event agent manages all event handling, so is at the top of the call chain while an application is running.)
OOPC 1.3 comes with a fully interactive class browser and object inspector. Figure 2 shows the browser. Any data area that shows a class, object, or array of objects or methods is an active field that can be clicked on to bring up an inspector window.
The class browser is helpful in both learning OOPC, and for debugging. OOPC also has another valuable debugging tool: execution trace debug files which can be created during a debugging session at the switch of a compile option. A wrong or out-of-order processing call is a common cause of problems with object-oriented programming. An execution trace file is extremely helpful in fixing such a problem. Also, class methods consistently use data checking with exception handling to minimize the introduction of bugs during development and facilitate rapid debugging.
For data management, OOPC provides a variety of collection, array and list classes. There are classes for unordered collections, queues and stacks. There are bit array and variable-sized data array classes. OOPC has a list class that supports variable-sized rows and columns. The class browser shown in Figure 2 uses a subclass of the basic list actor class.
OOPC includes both paint and graphic object classes. Pictures, icons, and a full complement of geometric shapes are provided.
A text engine is currently under development. OOPC currently has a styled text class that uses the Macintosh Toolbox TextEdit. The next major version of OOPC will sport a powerful text engine that fits the bill for platform-independence. Along with the text engine will come a cTextDoc class that handles text editor document operations.
OOPC's API is already platform-independent. The release of OOPC for Windows in late 1993 will be proof of the pudding.
