January 92 - In Transit to MacApp 3
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!