June 91 - Man About Town-News from San Jose
Man About Town-News from San Jose
Another Worldwide Developer's Conference has come and gone, MacApp 3.0's moving into
its next alpha phase, and a decision has been made about the official source language for
MacApp 3.0. Where should I start this week? How about with the latter?
MACAPP 3.0 AND C++
The word is out on the question of the MacApp 3.0 source, and it's official: Tom Chavez
reports that MacApp 3.0 is going to be maintained in C++, and that's it: a separate
source will not be maintained in Object Pascal or produced at a later date through some
sort of translation mechanism (one of the suggestions raised earlier).
Is that bad news for Object Pascal users and THINK Pascal types in particular? To be
honest, it could have been worse. True, you won't be able to read MacApp sources in
Object Pascal, but that doesn't mean you won't be able to program in Object Pascal.
Apple has been working with Symantec to make sure there's an optional switch so that
the MacApp library can be produced in a ".o" linkable format that's usable from the
THINK Pascal environment. You won't have MacApp source in Object Pascal; you will
have an Object Pascal-compatible library.
The biggest loss: you'll no longer be able to single-step through the MacApp sources
using THINK's wonderful high level debugging environment. And that's a real shame. So,
the question comes to mind-is it livable? Maybe a better question at this point would
be-do you have a choice? Like I said, it could have been worse.
CLIMBING THE FENCE
If you're an inveterate Pascal user like myself, what do you do? One choice is to stay
with THINK, shrug your shoulders and just accept the situation. Another is to maybe
shudder a little bit, then settle in for a long session with Bjarne Stroustrup's "The C++
Everyone's got to make their own decision. Me? I'm making-very hesitantly and with
no small degree of anxiety-a painstakingly slow move across to the C++ side of the
fence, after some time spent with THINK C along the way to help fortify my nerves.
But it's tough, it's tough. It's almost embarrassing to see a grown man like myself
reduced to such a trembling mass of shakes and quivers. I'll keep you informed as to
whether or not I survive the transition. For motivation, I've got a fun little project in
mind, that will also get me into Apple Events. I'll be reporting in periodically.
PASCAL '9X UPDATE
Here's something I wanted to talk about in my last column, but it got crowded out by
other issues. Derek White from Kurt Schmucker's ATG group in Columbia, Maryland has
been quietly working away on the official language specification for Pascal '9x. It's
hoped that this project will provide a version of Object Pascal that's feature-compatible
with the object-oriented extensions in C++.
Much of Derek's work now consists of formalizing the conclusions that were reached
during the '9x session held at the MADA conference in February. He sent me a note
summarizing what happened during the session, and I want to quickly run through some
of the highlights.
About 45 developers sat in for the four-hour round table discussion. Derek got a hand
running things from Kurt and Harvey Alcabes. There was a general consensus that it's
important to ship a product as soon as possible, and that in order to do that, the language
should be released in phases, with the core, essential features coming first.
MOST POPULAR REQUESTS
Harvey took a poll of what features developers wanted. The winner, far and away, was
better encapsulation of data using a mechanism similar to C++'s use of public,
protected, and private keywords. As Derek stated, this one's a real winner. It's not that
hard for compiler writers to implement, and users find it pretty easy to understand.
What turned out to be more surprising was that everybody wanted to see value-based
objects, in which an object variable is the object itself, rather than a reference to an
object through either a pointer or a handle. Value-based objects are also referred to as
stack-based objects; they get allocated and deallocated automatically on entry to a local
To be sure, if you still want an object reference, you can just declare the object as a
pointer to a class. But all you C++ nerds knew that already; it's just us unregenerate
Pascal types that have to figure this sort of thing out for the first time. (It hurts my
Finally, in the features race, abstract methods and classes placed a distant third.
Most of the session seemed to deal with the issue of constructors, a topic that confused
just about everybody. Fully a third of Derek's summary was devoted to more than I ever
wanted to know about the subject-be happy that I'm not passing that information on to
you! Lots of suggestions were made during the session, but no final consensus on
constructors was reached, except that a lot more exploration was called for.
And that's what Derek's been doing since February, with an occasional week off to join
his ANSI colleagues from DEC, Microsoft, and Symantec as they work at developing a
standard set of features for an object-oriented extension to Pascal. (Now I know what
compiler writers do to relax in their time off!)
I came back from the Developer's Conference in San Jose with two amazing pieces of
documentation: Volume 6 of Inside Macintosh and a slim, unprepossessing little volume
titled the Apple Event Object Support Library. First about the new Inside Macintosh…
The scary thing about the new volume is that it's over 1,800 pages long-but the
scarier thing about the latest Inside Mac is that it's all new. This volume doesn't replace
the first five volumes, it appends them! The entire volume deals strictly with System
7.0-related information, and it's immense!
This is the first time I've paid attention to System 7.0-I guess I subconsciously
considered it vaporware until I finally saw the real thing in San Jose-and now I find
myself torn between a heady fascination with all the new technical information, and
pure, palpitating fear at the scope of what I'm going to have to learn to bring myself up
I mean, we're talking major insecurity; there's a lot of stuff here. It strikes me that
the stakes for Apple developers have just gone up tremendously. You know, I thought I
already paid my dues!
APPLE EVENTS ARE KEY
I've been spending hours and hours reading and rereading Chapter 6 on the Apple Event
Manager. It strikes me that this is the core of what's most important in System 7.0, and
that it has far reaching implications.
What those are exactly, I don't have much of a clue at this point. It's more just a sense
that the whole concept of cooperating applications is going to radically-and I mean
radically-change the way we view the Mac. I don't think anybody can visualize all the
ramifications at this point. But it's pretty clear that Apple events are key.
APPLE EVENT OSL
Which brings me back to the other piece of literature I brought back from San Jose. The
Apple Event Object Support Library documentation is a lot slimmer than its Inside
Macintosh cousin, by at least an order of magnitude, but I think it also has ramifications
that are probably just as important in the long run.
Again, this is just a sense on my part. Because, to be honest, I don't understand half of
what's in this little guide. It's not too difficult; on the contrary, it's far too easy! It just
happens to present some concepts that are different enough from the way I'm used to
thinking that I haven't had that "Aha!" experience yet, where everything suddenly falls
into place with a bright, crystal-clear focus. But it's coming; it's coming-I can feel it!
So what does this slim little volume talk about? If I understand correctly-and again, I
couldn't swear to it -Apple Events describe a protocol for specifying how data is to be
transferred back and forth between applications. However, it doesn't say anything about
the internal significance of the data. That's up to your applications to agree on. And this
is where the Object Support Library comes in.
What the OSL does, apparently, is provide a language that applications can use to talk
about their data and make meaningful requests of each other, without having to know
anything about the internals of their data. It's like a protocol for data, similar to the
Apple Event protocol for event messaging. And I think it's going to form the basis for
some very interesting high-level scripting stuff coming down the pike. If you're
interested in interesting things, the future looks promising indeed!
Does all this sound sufficiently vague and rambling? Do you think I've been smoking
too many bananas? As I said, I don't fully understand all of this yet; it's just clear that
it's nifty-peachy-keen, and it's going to be very important a year or two down the road,
maybe less! So if I were you, I'd immediately run out and join the Apple Event
Developer's Association and pick up a copy of their OSL specs. I don't have a mailing
address handy-contact Apple if you need one-but their AppleLink address is (surprise!)
THE MACAPP CONNECTION
Is there a MacApp connection to all this rambling, you might ask? Of course! There's
some pretty good support built into MacApp 3.0 for Apple Events, particularly if you
want to send them. There's not as much support built in for receiving them, if you want
to play at being an Apple Event server, but that's coming. Remember, we're still pretty
early alpha at this point.
There is no support right now for the Object Support Library, but that'll be showing
up with the first beta of 3.0, according to Eric Berdahl, who's been pushing hard to have
that happen. Eric has been doing some good stuff with Apple Events. He's got the C++
source for a nifty little application called "FotoMac" on the MADA conference disk. It
does a nice job of showing how to do some simple Apple Event messaging in MacApp 3.0.
Take a look.
That's it for this week. Back to Inside Mac, Apple Events, and perhaps some play in
C++. You Pascal programmers out there, take heart; chin up-the future's rosier than