Man About Town-News from San Jose

Howard Katz

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++ Programming Language."

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 stack frame.

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 head!)

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!)

VOLUME VI

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 to date.

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!) AEDA.

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 you think.