Viewpoint

By Scott T Boyd, Editor-at-Large

Under a clear night sky, high in the Colorado Rockies, far away from the usual trappings of techno-society, I sit, quietly writing C++ code while the rest of the world sleeps. Many years of conditioning make this the perfect time to work. Unfortunately, it’s right in the middle of the first vacation I’ve taken in a couple of years (and a family get-together, at that).

Object oriented programming - it’s all the rage. A few years ago, it was touted as the thing that was going to take us to the next level. While I’m quite happy to acknowledge many of the advantages, somehow I’m still stuck sitting here using up precious vacation time writing object oriented code. Given that, I have to say that OOP isn’t exactly living up to its promise.

Why? For one thing, the tools we generally choose to use are crude at best. C++ just doesn’t have the set of support tools that Smalltalk does, nor does it share Smalltalk’s dynamic, interactive nature. Yet, for some reason, we seem to prefer stone axes. To make it even more interesting, just about the time someone comes up with a tool that’ll handle things, someone else decides that the current scheme isn’t clever enough, and adds something to the mix (like SOM) that makes the currently-good-enough tools less useful. Before we even get started, we find that we need all-new frameworks, and they need all-new view editors, debuggers, and so forth.

When I first dove into my current project, I was handed several megabytes of C++/SOM source code, written over the previous year or two by a small, experienced team. “What a great time to break out Object Master and speed-learn the project,” I thought.

The project is OpenDoc-based, so it’s broken up into a bunch of projects in a sizeable Projector hierarchy, and MPW drives the build process. At the time the project was started, CodeWarrior was the way to go for PowerPC code (which was, at the time, the only way to get CFM support), so each of the pieces has a CodeWarrior project file, and MPW builds each piece into a CFM library by sending apple events to CodeWarrior. It’s a bit twisty, but makes sense, given the timing and specific technology requirements.

Object Master seemed like just the tool for speed-learning the project. Even though it didn’t have a way to add all the sources in a nested set of folders, it eventually did a nice job of displaying and navigating the object hierarchy. I found there were a few things that were difficult to do with Object Master, and I couldn’t figure out whether it even knew how to do some of the things I needed. I was surprised to find that none of the several friends and coworkers I asked had any significant experience with it.

While looking for workarounds, someone suggested MacBrowse. While it isn’t as slick as OM, it revealed some serious browsing power. Nevertheless, it, too, has its limitations. For example, while it can give you the file name of where a function is implemented (not the path, which makes the file name nearly useless in a multi-folder project), it can’t open the file, nor will it send an apple event to your editor of choice.

Both tools do certain jobs well, but I find that I still do most of my editing and browsing in MPW. Its editor is not only finely-honed, but, by working with a single editor, I avoid the unfortunate synchronization problems that crop up when I have a file open in more than one application. There just doesn’t seem to be one really good way to edit/browse when working on projects like this just yet. Maybe this is a job for OpenDoc

The real stone axes come into play when PowerPC SOM code needs debugging. It’s no longer an issue of whether it compiles and links, but we’ll get to that another time.

We’ve got a ways to go before the tools are up to doing the job so we can spend a little more time on vacation and less on building things that compilers, view editors, and linkers (as well as the rest of what ought to be in our development environments) should be able to do far better and faster. In the meantime, it’s time to start a build (just how many times can this compiler recompile these header files that haven’t changed in recent memory, anyway?), go back outside, and enjoy watching the moon come up over the mountain.

From the “Couldn’t Buy A Clue” Department

I’ve been giving Apple a hard time lately for just not getting it when it comes to the hows and whys of supporting developers. The saga continues. This e-mail travesty wins my award for Completely Missing the Point:

To: devsupport@applelink.apple.com
I have a neat WWDC Presentation CD. One problem. No Persuasion player. I’ve looked everywhere. The 
MacOS SDK has version 1.01 which will not open the documents on the Presentation CD. HELP!

From: Developer Support Center
We received your email regarding the WWDC Presentations CD and the inability of Persuasion Player 1.01 
to recognize it. I apologize for the delay in my response. I’ve been waiting for more information to give you. 
Unfortunately, you do have to use the full Persuasion application, Persuasion 3.0 in order to recognize the 
files on the WWDC CD.  Your local software dealer should carry Persuasion 3.0.
    Please feel free to contact me at DEVSUPPORT or 408/974-4897 if I can be of further assistance.

Food For Thought

It’s important for everything to not know what everything else is doing. That’s the beauty of object oriented programming.

- Rudy Baylor, Memphis, Tennessee

Evidently, large corporations figured out the beauty of object oriented programming years ago.

- Jim Shorts, College Station, Texas