As Easy As A, B, OOPC?

Mark D. Gerl

The intent of this article is to provide you with an introduction to Electron Mining's OOPC, the newest player in the object-oriented software development game. I'll tell you what you get with OOPC, what you can expect OOPC to do for you, and what kind of service you can expect from Electron Mining, based on my personal experiences. Finally, I will give some insight into what OOPC is best suited for and even add some of my own opinions.

This article will not tell you how OOPC does its magic, otherwise it would just be a plagiarization of the OOPC manual. In addition, I will not waste any trees comparing (in whole) MacApp or the THINK Class Library (TCL) to OOPC because that would be like comparing apples to oranges (comparisons of this sort are based on individual requirements and needs). Readers will have to make their own overall comparisons. For the record, OOPC version 1.1.6 is being considered at the time of this writing.

introduction
What is OOPC?

OOPC (pronounced "oop-see") stands for "Object Oriented Programming in C". Rather than being an extension to the C language, OOPC is more like a sophisticated use of ANSI C. Through clever use of macros and function calls, OOPC provides C programmers with a highly flexible, fully dynamic, object-oriented development system. Being modeled somewhat after the Common Lisp Object System (CLOS), OOPC's object-oriented features support list is very aggressive and reads more like a wish list. Along with the expected features, OOPC also supports the following object-oriented capabilities:

• Multiple inheritance
• Class variables
• Function overloading
• Dynamic object binding
• Dynamic class definitions
• Dynamic inheritance (objects can change their inheritance at run time)

Being ANSI C bound does limit OOPC's OOP completeness. For example, OOPC does not provide support for operator overloading, default method parameters, or protected/private method and data access.

It is clear that OOPC has no roots in MacApp or TCL, except where the Macintosh Toolbox was modeled. Instead, OOPC provides its own class architecture. In any case, Electron Mining doesn't appear to be in any immediate danger of lunging legal personnel from Apple looking for their next victim.

Just Say No (to the Toolbox)

Designed to be platform independent, OOPC provides a complete abstraction of the Macintosh Toolbox. This means that you will not be making calls directly to ROM routines unless you're extending OOPC's functionality. For example, OOPC provides its own calls for memory management, drawing environment (including offscreen), events, printing, and file I/O (including resources). Whereas OOPC internally uses styled TextEdit in its current version, it does not call the Memory, Dialog or List Managers. All this means OOPC is uniquely prepared to go cross platform. Electron Mining admits it is working on a Microsoft Windows version at this time.

Substance

Being no slouch for content, OOPC contains about 60K lines of code, around 90 classes, and too many system functions and methods to count. In addition, source code is included for a floating window WDEF, a popup menu CDEF (thus eliminating the need for the buggy System 7 CDEF), and the OOPC Browser INIT (referred to in this article as the run-time object inspector for the THINK C Debugger). Electron Mining also provides OOPC Tip Sheets (in THINK C text file format) which are designed to augment the user manual. Accompanying all this electronic data is a 420 page indexed manual that is purely for user reference.

Demo Draw

OOPC ships with a fairly complete sample application, called "Demo Draw". A built Demo Draw application (287K in size) is roughly 2355 lines of application code, not including the actual draw classes. These tear-off tools, colors, and colors palettes, tool and draw object actor classes, etc. are themselves reusable (and nicely separated from the Demo Draw application code) and thus can be considered generally available and part of OOPC. To help quantify the functionality gained from the number of code lines, OOPC's Demo Draw application supports the following features:

• Six draw tools including a polygon tool, a text tool, and the arrow selection tool; Draggable, resizable, colored, patterned, filled objects including their border lines;
• Custom pen sizes;
• New, Open, Save, Save As, Revert, Page Setup, and Print commands;
• Undo / Redo and clipboard support (but no Show Clipboard command);
• Page boundaries, offscreen image buffering (memory permitted), and 2D scrolling; and
• Multiple open documents, automatic window tiling, and smart window zooming.

For the sake of doing comparisons, MacApp 3.0.1's C++ samples range in size from Skeleton at 1036 lines of code to DemoDialogs at 3416 lines to Calc at a hefty 9172 lines of application code.

Development Requirements

The advantage of being ANSI C based is that OOPC developers can use either Symantec's THINK C 5.0.x programming system or Apple's MPW 3.2. Developing for OOPC therefore requires minimal development resources (standard THINK C or MPW partition sizes). This may make OOPC the only object-oriented development environment other than TCL to run on a System 7 configured Macintosh with only 4MB of RAM. Scary thought.

Out of the box, OOPC is better suited for THINK C development than for MPW C. It ships with all the OOPC source code in THINK C file formats and the code resources as well as the Demo Draw and starter applications have THINK C projects. Electron Mining claims that OOPC code is fully MPW C compatible, but unfortunately, there is no MPW make file. MPW C users will need to create their own make files until one is provided (Electron Mining is working on one at this time).

the sum of the parts…
Dynamic Everything

Everything in OOPC is determined and bound at run time. This makes OOPC applications open slightly slower than normal applications, but the internals are more flexible than static systems. OOPC even allows objects to change their inheritance midstream. Because classes and objects are fully dynamic, it is possible for different objects (instances) to have different data even if they are of the same class type. This degree of flexibility is both one of OOPC's strong points, and one of its weak points. While an object is always going to dispatch to the correct method based upon the inheritance chain, it is possible to change inheritance so that a subclass overrides a method that you think is going to be called. This can happen with other object systems too, but it seems more likely with OOPC, precisely because OOPC is so dynamically flexible and it doesn't warn you of such happenings. You'll need to practice safe OOPC to keep yourself out of this kind of trouble!

Verb Functions

OOPC provides over 160 verb functions (with encouragement for developers to add more). A verb function is a polymorphic C function call. The correct method is dispatched to based upon the class of the object passed. Verb functions are required to access class methods. Whereas class objects encapsulate data, verb functions encapsulate behavior. For example, to draw an object you would use:

draw(theObject);

In making this verb function call, the OOPC dispatch mechanism is called and determines which actual method code to call. The actual method doesn't even have to be named "draw", it only needs to be associated with the draw verb function at class definition time. Verb functions are like CLOS generic functions, and can be considered OOPC's version of a C++ VTable.

The Root of All Evil

The root class of OOPC's class library is cMetaClass. This class provides all you'd expect from a root class including file I/O (object persistence) and cloning. The getdata() method allows you to access a copy of the object's data. There are even methods that allow you to dispatch to multiple objects in a single verb function call. For example, if you want to close all open document objects you would use:

apply(cDocument, close);

OOPC's 007

OOPC uses agents to encapsulate behavior as opposed to data-like a subsystem in the traditional sense, but related to a particular class. For example, a PrintAgent is related to the cPrint class, but handles the entire printing process, while allowing the process to be easily modifiable. This agent handles the page setup and print job dialogs in addition to the actual printing, all of which are interrelated.

In addition to its mission (the agent's main behavior function), agents have something called modification points. These are interaction points that allow different functions to be executed as the agent runs-which modifies the behavior of the agent on the fly (e.g., revoking its license to kill). Modification points are like method overriding, but in a different context.

The EventAgent, for example, can be modified (on the fly) when the application is creating and presenting a new modal dialog to the user. The application calls define_missions() for the EventAgent disallowing certain events (mouse downs outside the dialog, etc.), but still acts on dragging the dialog window, etc.

Another agent example is the WindowAgent. It does what the Macintosh's Window Manager does-keeps window ordering, handles floating windows, etc. The WindowAgent doesn't access any window data, but it does keep a list of window-related stuff.

Your Toolbox or Mine?

As previously mentioned, OOPC's class library is designed so there is no need to make Macintosh-specific calls for user interface, events, resources, memory management, drawing (offscreen), file I/O, printing, etc. Not using the ugly Dialog Manager, OOPC's alert and dialog capabilities rival MacApp's. In parallel, OOPC's home-brewed lists can contain icons, sounds, or any objects for that matter. This means that if you're a fluent Macintosh Toolbox programmer, you'll need to think in OOPC terms instead of Toolbox terms. Now, now, it's not that bad; for example: AddResource() becomes add_resource() in OOPC. OK, OK, some of the parameters of these abstracted methods have changed as well, but that's because the functions have packaged more functionality than their Toolbox equivalents. In any case, with OOPC being well-suited to cross-platform use, it will best serve those new to Macintosh (or Windows for that matter) and those new to OOP.

Memory Management

One of OOPC's strongest points, its internal memory management scheme is blindingly fast-compared to using Macintosh handles or pointers. The scheme is optimized for handling a large number of allocations (greater than 10,000). The more allocations, the faster OOPC's memory management becomes (relative to pointers and handles). OOPC doesn't use handles, so you don't run into the dangling pointer problem you often see in early stages of Macintosh application development. This faster, but less efficient memory scheme (OOPC always allocates at least 32KB at a time) has its tradeoffs. Then again, if you want, you can change it, because you have the full source code. [See the article on OOPC Memory Management elsewhere in this FrameWorks issue.]

Event Processing

OOPC has an asynchronous multiple (five) priority event processing scheme. These five preset event priorities, ordered from highest to lowest, are: ASAP, OS, TIMER, USER, and SLOW. The event priority queues are extensible: new priority queues can be added simply by adding C #defines (no other coding required).

The EventAgent is repeatedly called (by the application agent) to handle events. The EventAgent decides which events to handle and initiates processing. Each event priority has its own event queue. TIMER events are for handling periodic or repetitious events. ASAP, USER and SLOW events are used for intra-application communication and asynchronous processing.

OOPC defines 22 different OS event types. For instance, instead of having one mouse down event and switching on it, OOPC defines 9 different mouse down events (e.g., down in desktop, down in menu, down in drag, down in grow, etc.). Identifying double-, triple-, etc. clicking is handled automatically by OOPC. Also, the EventAgent maintains the mouse click location in both local and global coordinates. The EventAgent has a modification point defined for each of the OS event types. This is how you would mask out certain types of events at certain instances in an application's execution.

Too Persistent You Say?

All OOPC objects are persistent. That means file I/O is handled for you. The root class, cMetaClass, has methods for saving and restoring objects. Only a few methods are involved: save(), getfileinfo(), write(), read(), restore() and associate(). The cResource class has built-in persistence for resource-based objects. Writing method overrides for default file I/O handling takes very little code, however, the only time you'd need to override file I/O methods would be if an object saves data in the file differently than the way it's stored in memory.

Linking Objects

Links (dependencies) between objects can be set up and then automatically maintained for you by OOPC. Objects can be linked to each other with the bind() verb function, and dissolved with trash(). Objects can be automatically released when links to them no longer exist. Object links are persistent, so any links established can be saved to and restored from associated files. Links that cannot be resolved during file restoration are forgotten.

Object-Oriented Data Base Foundation

While OOPC doesn't handle an OODB automatically for you, the foundation is laid through: 1) persistent objects, 2) links between objects, and 3) garbage collection-disposing objects when links no longer exist. You would need to add your own sorting and searching to get the full power of OODB technology. OOPC's support for OODBs is a memory-based scheme and not a disk-based or virtual one. However, after giving a cursory look into extending OOPC to support either of these other schemes, it would appear to be a fairly simple task for a developer with well defined OODB criteria. Still, the built-in OODB power that OOPC has is surprising.

Document Management

OOPC provides extensive yet simplified document management. OOPC automatically handles document objects. For example, documents automatically display themselves in a window, automatically manage offscreen display buffers (memory permitting), can save themselves to or restore themselves from files, and print themselves. In addition, documents automatically handle clipboard (scrap) operations as well as undo/redo. All this is possible because cDocument objects are really persistent agents. If an OOPC application only has one type of file, cDocument can be used directly and does not need to be subclassed. This built-in functionality is unparalleled in MacApp or TCL.

One Exception

Exception handling in OOPC is similar to Display Postscript. You can discover errors as they occur, report errors immediately, and recover gracefully. Errors that occur during application initialization are handled by the exception handling code in main. The EventAgent's mission catches errors once an application has been initialized and is running. Numeric error and message codes are converted to text and reported to the user automatically. There are typical failure checkers for NULL pointers, OS errors, and invalid addresses (i.e., objects). OOPC defines a list of standard errors which get activated at certain points in the code by the function call:

raise_exception(anError);

OOPC defines some macros (as shown below in all-caps) that make the code more readable. An example code block with exception handling in use might look like the following:

object some_method(object self)
    {
    CODE
    /* put code here            */
    /* use raise_exception()    */
    /* to activate an error or  */
    /* one of the fail macros   */
    HANDLER
    /* exception handling code  */
    CONTINUE_HANDLER
    return self;
    }

Handlers can be nested, as you'd expect. In addition to the CODE, HANDLER, and CONTINUE_HANDLER macros as shown in the above code fragment, OOPC has macros that define the end of the handler, re-raising an exception, and various types of returns.

Debugging Support

If you use the THINK C environment, there is a run-time object inspector added-in (through an INIT) to the THINK C Debugger. In addition, OOPC provides extensive execution trace file support that prints parameters, calls, etc. with automatic indenting and formatting. Developers can enable / disable the trace file at will for repetitive actions (e.g., dragging an object might create a lot of output, so the trace can be disabled prior to dragging, then re-enabled afterwards).

Goodies

OOPC provides some interesting goodies for developers. Tear-off tool, pattern and color palettes are done for you (and implemented in Demo Draw). The pattern and color palettes work together to allow colored patterns. In addition to the typical user interface classes are classes for arrays, collections, dates, rules, pens, sounds, code segments, memory watching (which is automatic), floating lists, and more.

Patch No Trap Before Its Time

This wine is still aging, because OOPC by itself does no Macintosh trap patching. Funny though, the system code library provides functions for easy trap patching. In addition, OOPC has a run-time Pascal function jumper that allows you to have a definition function (WDEF, MDEF, CDEF, etc.) directly in code, as opposed to being called as an external resource. While it's easy to think of OOPC as the Macintosh version of a cross-platform development environment, it also provides developers with bonus Toolbox functionality that it doesn't even use.

OOPC stagnant? Not!

If Electron Mining were to just publish OOPC as it is now and just forget about it, OOPC would have a very short life span in this rapidly changing leading-edge industry. Thus far, Electron Mining does not appear to be supporting OOPC in the same passive manner as Apple supports MacApp or Symantec supports its THINK products. Electron Mining has followed up OOPC's introduction with several unsolicited upgrades. In the three months I've had OOPC, I've received five free upgrades which included not just bug fixes, but new features as well. If Electron Mining continues to support OOPC in this unusually good manner, they'll perhaps be the only development tools company within this industry that does so.

Electron Mining is openly informing its OOPC developers what new features they are currently working on, and encouraging feedback on features developers want. The next major version, 1.2, is due by the time you read this, and will include: Apple Events support (but not the Object Model), a poster class for working with huge graphical work spaces (up to 37 feet square), and some other non-System 7 features. Developers can also expect an enhanced manual with a new tutorial section.

Electron Mining is also working on a full text engine for OOPC that will not be based on the Macintosh Toolbox's styled TextEdit. Though it may be there, Electron Mining will not commit this feature into version 1.2 due to the shipping deadline.

Following version 1.2 is the first Microsoft Windows version of OOPC (including the necessary text engine mentioned above). Electron Mining says they are continually swamped with calls from Intel lovers for a Windows version so they can utilize OOPC's power on their favorite PC.

OOPC support

In addition to the free OOPC maintenance upgrades, Electron Mining has consistently provided less than one day turn-around time on electronic mail messages (through America On-Line) and has been able answer all technical and non-technical questions over the phone (though not toll free). So far, Electron Mining seems very committed to loyal customer satisfaction.

pros and cons

Pros

• Substantial class library with full source code.
• Fast memory management.
• Automatic object persistence and document management.
• Debug tracing, exceptions, and run-time object inspector for the THINK C Debugger.
• No trap patching.
• Visual elements follow Apple's Human Interface Guidelines.
• Abstraction from the Macintosh Toolbox, built on ANSI C to be portable.
• OOPC's 420 page fully indexed reference manual.
• Electron Mining's quick and responsive support and free bug updates.

Cons

• No ViewEdit or MacBrowse like tools.
• No run-time object inspector for MPW developers or a pre-made make file.
• Could use better Gestalt-like support.
• Missing System 7.x support (Publish and Subscribe, Apple Events, Balloon Help).
• No Communications Toolbox or QuickTime support.
• No quick-start tutorial section in the current manual.

Conclusions
Not For Everyone

OOPC, like any other class library, language, or development environment, is not for everyone. Because of the paradigm shift from either the emerging C++ standard or the dying Object Pascal era, OOPC is best suited to users new to OOP technologies, but not new to programming in straight C. OOPC is obviously not an environment you would port an existing body of code to (unless it was written in C or CLOS), and therefore you will want to design OOPC projects from the ground up. OOPC also doesn't require programmers to have intimate knowledge of Inside Macintosh or the Macintosh Toolbox for that matter and is, therefore, uniquely suited for cross-platform development.

Nothing in the world of software development is as easy as ABC, especially when the Macintosh is involved. OOPC is no exception to this rule, but if you fall into any of the above-mentioned categories OOPC is definitely worth a serious look. If you are someone who really dislikes the C programming language, you may have to wait for Dylan to get some of OOPC's power and flexibility (or forge ahead with Macintosh Common Lisp).

Summary

Using your choice of the fast THINK C 5.0.x development system or the powerful MPW, OOPC provides the power of Common Lisp Object System within the familiarity and flexibility of the ANSI C programming language. See the article "Comparing C-Based Object Systems" in the Nov./Dec. 1992 issue of FrameWorks for a comparison of how OOPC stacks up against C++ and Objective-C.

Although knowing some details of the Macintosh Toolbox (QuickDraw in specific) is a plus when programming with OOPC, it is not necessary due to OOPC's high-level abstraction of the user interface, memory management, and file I/O. By providing access to full source code, Electron Mining is encouraging developers to enhance or even change OOPC.

Electron Mining For Gold

Electron Mining's substantial initial offering of OOPC is available now. As a development toolkit, OOPC is a full-bodied powerhouse. While Apple and Symantec spend the next year or more arguing over features, implementing, and perfecting Bedrock technology, OOPC is here today with complete source code, ready to be embraced, improved, expanded, and deployed. If Macintosh developers embrace OOPC and Electron Mining can deliver a Windows version of OOPC before Bedrock ships, the predicted future of cross platform software development (involving the Macintosh) may not be left in the crystal ball after all.