ADVERTISEMENT

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++.