July 93 - OOPC
OOPC
Gary Odom
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.
Object System
OOPC's object system was designed to allow flexible object-oriented programming in
C. The OOPC object system was created in 1988 for an artificial intelligence program.
The specific design goals of OOPC's object system, all of which were achieved, were as
follows.
• Standard C syntax that works on any C compiler.
• Multiple inheritance.
• Dynamic definition of inheritance and method attachment, where classes
and objects are completely defined (and can be modified) at run-time.
• Fast execution speed.
• Flexible usage of classes and objects: allowing a class to have its own data,
separate from the objects it creates; and allowing object methods (separate
from the class an object inherits from).
• Enforce a simple API.
• Provide dispatch control (before- and after-methods) that maximize code
reusability.
• Provide an abstraction mechanism for subsystem processing (which
classes do not provide).
• Garbage collection and support for object linkage (necessary for both
garbage collection and OODB).
• Provide support for collections, which are integral to OOP.
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.
Application Framework
The design goals of the application framework were as follows.
• A streamlined class library architecture for simplified learning and
maintenance.
• Full user interface feature set.
• Simple but sophisticated rule-based activity control.
• Automatic document management.
• Data management.
• Built-in object persistence that can be applied to new classes with little
or no additional code.
• Multiple-priority event processing, include threading.
• Accelerated memory management optimized for a large number of blocks.
• Comprehensive, sophisticated exception handling.
• Good debugging tools.
• Object-oriented graphics package.
• A universal language styled text engine.
• Platform independence.
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.
Conclusion
OOPC's object system was designed to yield maximum object-oriented flexibility and
power using standard C, and enforce a simple, consistent API. OOPC's application
framework was created to provide extensive support for accelerating development for
a wide range of application types and needs. Four years old and already a mature
product, OOPC class library development is ongoing in an effort to broaden its scope,
providing further acceleration for application developers.