Aug 95 Viewpoint
- Jan 95 Viewpoint
- Feb 95 Viewpoint
- Mar 95 Viewpoint
- Apr 95 Viewpoint
- May 95 Viewpoint
- Jun 95 Viewpoint
- Jul 95 Viewpoint
- Sep 95 Viewpoint
- Oct 95 Viewpoint
- Nov 95 Viewpoint
- Dec 95 Viewpoint
Volume Number: 11
Issue Number: 8
Column Tag: 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