In Transit to MacApp 3

Howard Katz

I've been away from FrameWorks for a few months, but I haven't been away from the Mac and MacApp. I've made a move from Pascal to C in my own programming work-initially, with a lot of trepidation-and I've also done some playing around with beta versions of MacApp 3, pursuant to jumping into C++ with both feet. First, the news…

MacApp 3 final-getting close

According to Tom Chavez, MacApp's product manager at Apple, there are about 125 MacApp 3 beta sites out there, all merrily compiling away on beta number 3, digging up bugs galore. It saddens my heart to tell you this, but yes-there are bugs, though the number is diminishing with each successive beta release.

As I write, beta number 4 will soon go out to the seed list, a few short weeks before Christmas. If schedules hold, the final release of MacApp 3 should be finished and ready to go by the end of January-theoretically, about the time you're reading this. Tom says that even if that happens, though, it's unlikely that the documentation will keep pace with the software development, so you probably won't see a version that APDA can ship on the street before MADA's Orlando conference in February.

Ditto to Jesse

Jesse Feiler wrote a nice little piece for the last FrameWorks on his experiences in moving from MacApp 2 and Object Pascal to MacApp 3 and C++. I suspect the information that Jesse provided will be helpful for other developers who are going to be making the same move. It was for me.

In getting ready to move into C++, I've just made a similar though smaller transition of my own-from Pascal to C. I can strongly echo at least one of Jesse's sentiments-if you're going to make the language jump, dive right in. Stop reading about the language, just do it.

I had a lot of trepidation before making the move, and about one anxious week of trying to figure out what things weren't working and why. But that was it; it was relatively painless.

I spent four months on a C language programming project about four years ago, so this wasn't my first exposure to the language. But it didn't "take" very well the first time around. This time, for whatever reason, it did. I'm enjoying it.

Mostly bigger, hopefully better

I finally got a copy of MacApp 3 running on my system, though I haven't done anything serious with it yet. I'm still in the MacBrowse exploring stage. As it is, MacApp 3 grunts and wheezes and barely runs on my machine. I've an old, stock standard Mac II. I had to dig into the bank account to upgrade my RAM from 5 to 8 megs to get MacApp 3 to compile at all, and it complains bitterly at that. MacApp 3 development really requires 9 megs, or 8 megs and virtual memory, and that I don't have at the moment.

This seems pretty incredible to me. I can remember-though I'm not sure I want to-compiling MacApp applications on a Plus. Such a thing is no longer within the realm of possibility, even as a thought experiment. The main villain, I'm told, is CFront, which requires-this is no typo-5 megs to run. Great Caesar's ghost!

It seems that just about everything about MacApp 3 is bigger, and that doesn't necessarily mean better. Disk space requirements provide another example. I've got an external 40 meg drive hung off my machine that I use only for occasional programming projects, and amazingly enough, it's too small. I used to do everything on a 40-meg hard drive; now it's not even large enough for MacApp, let alone anything else.

It's easy to see why when you look at the numbers. My MPW folder, little changed from the way it arrived in the mail, is well over 12 meg, and my MacApp folder is over 21. The latter number, on your system, will depend on the number of different versions you need to compile MacApp in. There used to be just two: "Debug" and "NoDebug." There are now a minimum of four, when you factor in whether or not you're supporting System 7. Just my ".NoDebug Files" folder, created by MacApp, is well over 3 megs.

New idioms galore

RAM and disk requirements are a downer, and I haven't even talked about compile times yet. But everything else is peachy-keen. There are new idioms galore. How's the following for a good example of some of the potentially baffling and interesting new things in MacApp 3? This little gem is right out of TObject:

pascal void TObject::UpdateDependents(
                ChangeID theChange,
                TObject* changedObject,
                TObject* changedBy)
{
CDependentIterator iter(this);
for (   TObject* dependent = iter.FirstDependent(); iter.More();
        dependent = iter.NextDependent())
    {
        dependent->HandleUpdate( theChange, changedObject,
            changedBy);
    }
}

Coming into MacApp 3 from an MacApp 2 and Object Pascal background, I count at least five idioms here that are new to me. If you're new to C and object programming in particular, probably everything looks at least slightly bizarre. Even if you're an old and experienced C hand from way back, there are strange things happening here. The three clauses that determine the boundary-condition behavior of the "for" loop, for example, probably look somewhat, well, wrong. And yet, they do make sense-eventually.

How about the declaration "CDependentIterator iter(this)" in the above sample? That's worth at least a few minutes of silent contemplation the first time it's encountered in code. I know what a "T…" class is; what's a "C…" class? Can we all say "stack-based object" in unison? In other words, an object declaration where we really have the object itself, and not an indirect reference to one through either a pointer or a handle.

And what about the parameter the function takes-"this" in the above example? We've all been hearing about constructors; here's one in the flesh.

What else? What's a "CDependentIterator" anyway? Iterators are one thing; dependencies are something else again. The combination of the two is only slightly more potent than the nuclear-powered salsa that took my mouth out of action for two hours yesterday at lunch.

TObject, by the way, is quite a bit more beefed up than what I'm used to from earlier incarnations of MacApp. It's hard to believe this class once had a grand total of four-that's 4-methods, and that they were all we needed. By my count, TObject now has at least 36 methods. MacApp 3's new dependency-notification mechanism accounts for a good number of them.

References to the rescue

I had a few books open next to my machine as I MacBrowsed my way through the MacApp 3 source code. Occasionally I'd venture over to Harbison and Steele, the "official" C language reference manual. I'm told there's a C++ version out as well, but I haven't seen it yet.

Kernighan and Ritchie's "The C Programming Language" is also highly recommended. It's from Prentice Hall. Make sure you pick up the second edition when you go shopping.

I'll put in a plug for one other C++ language reference that I find myself dipping into and out of when I have a few moments to spare, and that's Dan Weston's Elements of C++ Macintosh Programming. Dan's discussion of C++ language features is based around a class library that he develops in the book. In many respects it looks like MacApp-two of the main classes are called "TApp" and "TDoc," respectively. Dan's a MacApp programmer from way back and makes the odd appearance at MacApp conferences. I've been enjoying the book and finding it useful.

I'll be picking up some of the other "great" C++ references over the next few weeks and will try and do some quick reviews in columns to come. In the meantime, I hope you had a good Christmas season and are looking forward to a sunny vacation in Orlando. Florida, watch out!