ADVERTISEMENT

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

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

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

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

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

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!