Sep 96 Viewpoint
Volume Number: 12
Issue Number: 9
Column Tag: Viewpoint
By Will Iverson
This issue marks the first of my tenure as Editor-in-Chief of MacTech Magazine.
Some of you may recognize me from my earlier role as Symantec’s Macintosh
Developer Relations Manager. I am excited to be at the helm of the magazine, and look
forward to its growth over the next year. Write me at editor-in-chief@mactech.com
with your ideas.
First, a brief comment about Apple Computer (leaving to others the lengthy
non-technical dissertations on “what Apple should do”). Suffice it to say that the
times may be a-changing, but that just makes for more excitement. Less than a year
ago, Sun had a mixed future, and Java was barely on the horizon. Some were even
wondering if the Power Macintosh might spell the end of Sun! Today Sun and Java are
Well, I think you get the point. The great thing about this industry is that both success
and failure are fickle.
Overall, there’s reason to be bullish. The Macintosh development tools market
has never been stronger. There are more tools out there than ever before, and more
people are learning to program. This is where the magazine comes in - we intend to
expand coverage to meet the needs of this burgeoning market. One important piece of
this is to challenge the ever-increasing marketing which inevitably comes with a
healthy market. Who really is fastest, provides the best results?
Another component is the expansion of our Web site to form the new MacTech
NOW. A problem with traditional print is the relatively long lag between timely news
and the appearance of the information in print. We’ve been online for over a year,
with over 1500 pages of back issues and online documentation. Now you can look to
http://www.mactech.com/ for breaking news in the Macintosh Developer Tools
community as well.
Mac OS 8, OpenDoc, SOM and Java
Pop quiz - what do Mac OS 8, OpenDoc, SOM and Java have in common? Give up? The
futures of all four are tied together in a fundamental, albeit confusing, way.
A fundamental problem with the current implementation of object-oriented
languages is the lack of a common calling mechanism - there is no easy way to mix and
match pieces of object-oriented code. The most common place you run into this is
trying to mix C++ libraries from two different compiler vendors in your project. For
that matter, even C++ code compiled under different versions of the same compiler
usually won’t mix. This makes life for third-party library vendors very difficult, as
they must maintain potentially dozens of different versions of their libraries. It also
makes it very difficult for languages other than C++ (such as Smalltalk or Prograph)
to make inroads into mainstream community.
There are two solutions. The easy but limited route is to develop a C++
accepted binary interface, or ABI. There are variants, but generally this model
takes C++ as gospel for how object-orientation works and provides a relatively direct
mapping. All compilers would then support this standard. This doesn’t work across
languages, and leads to annoyances like the pascal keyword in C. This is more or less
the route Microsoft has taken with Windows.
The hard but robust solution is SOM. SOM (System Object Model) was developed
by IBM, and in typical IBM fashion it is very robust, very powerful, and a royal pain
to use.
The Macintosh Way
The only company which can actually present and enforce such standards is Apple.
Apple has decided on SOM as a standard, and we are already seeing this technology in
OpenDoc. SOM will provide (among other things) the foundation on which the Mac OS 8
Appearance Manager is built. In addition, SOM libraries will finally allow us to share
code between different tools.
SOM finally allows us to dispense with talking protocols, and to get on with
generating content - in this case, code. There is a caveat, however. There are two
ways to access SOM. The nasty way requires learning a new language and writing
special .IDL header files, which are then mangled by an intermediate tool which
actually generates the proper .h files. The easy way is something called Direct to
SOM. (Do not confuse Direct to SOM with DSOM, which stands for Distributed SOM and
is beyond the scope of this text.)
With Direct to SOM, you essentially keep working in C++ as normal, and things
just work. The compiler is responsible for generating the proper code. This is also
the problem with Direct to SOM - it basically involves rewriting the compiler.
Metrowerks announced at MacHack that Direct To SOM was a principal component of
CW10, and Apple has also announced Direct To SOM support in MrC. If your tool
vendor doesn’t support Direct to SOM, write and encourage them to do so.
So what does this have to do with Java and OpenDoc? OpenDoc suffers a critical
flaw: a single misbehaved part can take down an entire document. Java, on the other
hand, suffers from a lack of any structured, well-designed component architecture. At
WWDC, Apple demonstrated a Java-based OpenDoc part which included access to native
code and other neat things, like automatic persistence. The best part: it was roughly a
page of code, a fraction of what it would have been in C++.