About MacApp
Volume Number: 3
Issue Number: 8
Column Tag: MacApp Applications
How to Think in MacApp 
By Howard Katz, British Columbia, Canada
This is very important. You must think in Russian. You cannot think in English
and transpose. Do you think you can do that, Mr. Grant?
With those immortal words, our hero, Clint Eastwood, alias Mr. Grant, steals a
Russian thought-controlled steath fighter, out-shoots his way from behind the Iron
Curtain, and flies to freedom. Learning to think in MacApp is a little like that
thought-controlled Jet Fighter. You must think in MacApp. You cannot think in Pascal
and transpose. Do you think you can do that Mr. Grant?
Thinking StarTrek in Object Pascal
If you’ve been at all intrigued by what you’ve been reading about MacApp and
object-oriented programming, you’re not alone. Apple’s been promoting MacApp
heavily, and a number of developers, myself included, have discovered that
object-oriented programming is a new and exciting way of doing and thinking about
applications. But if you’re even the slightest bit confused by what you’ve read, don’t
feel too bad - again, you’re not alone. I had a lot of trouble when I was first starting
out (an understatement!), and I’ve talked to other developers who’ve also experienced
similar difficulties. Much of my confusion centered not so much on MacApp itself, but
rather on the more fundamental language issues introduced by Object Pascal (aka MPW
Pascal). If you don’t have a good, solid understanding of what objects are and how to
work with them, you won’t have a hope in a hot place of understanding what MacApp is
all about.
This article, then, is an attempt to focus on a few of these new language issues, to
hopefully cast them in a new light. I don’t think my treatment here is really all that
different from what’s been presented in Apple’s documentation, in Kurt Schmucker’s
Object-Oriented Programming for Macintosh, or in earlier issues of MacTutor. In
some cases, it’s simply a question of emphasis, or of looking at a particular concept or
programming construct in a slightly different way.
To make this exposition as “real” as possible, I’m going to assume that we’re
writing a hypothetical Star Trek game and use that as a vehicle for my discussion (I
personally need to see lots of concrete code before I can understand new concepts; you
might be similar). Anyway, my apologies to Gene Roddenberry and Trekkies
everywhere for any mistakes; I’m not trying too hard to be accurate (although I am
trying to be objective).
As you’re probably aware, the fundamental new programming structure
introduced by Object Pascal is the object (if you knew that, a cigar). Objects are
simply packages of data, together with the specific code that acts on that data. Objects
present a good way of modeling the behavior of a particular programming entity.
In a Star Trek game, for example, a good candidate for such an entity might be one
of the many ships that are manipulated during the game. Let’s consider, for example,
creating an object that represents a Klingon warship. Such a Klingon object would
represent one ship in our game. It would use its data fields to maintain information on
its current weapons status, its position, and so forth. The methods belonging to the
Klingon object would manipulate this information to enact the specific behavior we
expect of Klingon vessels.
Creating this object in our program is going to involve coding statements in at
least three different places in the program. First, in an INTERFACE section of our
program we’re going to find something like the following:
TYPE
TKlingonVessel = OBJECT
fNumTorpedoes : INTEGER;
... { other relevant fields }
PROCEDURE TKlingonVessel.LaunchTorpedoes;
... { other relevant methods }
END;{ TKlingonVessel object type }
Notice, first of all, that this is a TYPE declaration, and that somewhere else in
our code we can therefore expect to find a corresponding VAR declaration for a variable
of this type. In particular, this is a declaration for an object type. This object-type
declaration is our first interesting extension of standard Pascal syntax. It shares some
of the characteristics of a RECORD type, except, most notably, that standard Pascal
Referenced by (2):