How to Think in MacApp

By Howard Katz, British Columbia, Canada

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 records don’t contain procedures as fields. Strange concept number one. Also note that the procedure name LaunchTorpedoes is prefixed by the object-type name, TKlingonVessel.

The naming conventions in the above piece of code, by the way, are just that - conventions. Object type identifiers start with a “T” and data fields start with an “f”. I’ll point out later why these conventions are useful.

Somewhere else in our program we’ll find an IMPLEMENTATION section that contains the actual code for the procedure (ie, method) TKlingonVessel.LaunchTorpedoes. It might look something like the following:

PROCEDURE TKlingonVessel.LaunchTorpedoes;
BEGIN
 IF fNumTorpedoes > 0 THEN 
 BEGIN
 fNumTorpedoes := fNumTorpedoes - 1;
 DoLaunch;
 END;
END;

The first interesting question I’d like to address is this: given this declaration of an object type and the IMPLEMENTATION of the single procedure it contains (or at least the single one I’ve shown), how do we invoke, or execute, the code for the procedure TKlingonVessel.LaunchTorpedoes?

If we were working in standard Pascal, the question would be so trivial as to be meaningless: you simply invoke the procedure by naming it at some point in your program. In Object Pascal, it’s not quite that simple. In Object Pascal, you can’t execute the code for this method until the object containing it has been created. And we haven’t created the object yet; we’ve simply declared an object TYPE, a template for the object to be.

This is one of the fundamental differences between standard Pascal and Object Pascal: in standard Pascal, code is fixed and immutable - it simply is. In Object Pascal, code has to be created on the fly at runtime before you can use it. Now, that’s a dramatic, though slightly inaccurate statement. It’s close enough to the way things work, however, to be useful.

How do we create the actual TKlingonVessel object and execute its code? The third piece of our program looks something like this:

 VAR
 aKlingonVessel  :  TKlingonVessel;
 BEGIN
 NEW( aKlingonVessel );
 aKlingonVessel.fNumTorpedoes := 10;
 aKlingonVessel.LaunchTorpedoes;
 ...
 END;

Obviously this piece of code is a wee bit strange - it’s unlikely that we’d create a new Klingon object and then immediately ask it to blindly launch a torpedo. I plead pedagogical considerations. At any rate, here’s the VAR statement for the variable I mentioned. This code fragment says that we’re going to create a new object, and that object will be of type TKlingonVessel as declared earlier. An object of this type will contain the data fields and methods that were declared for that object type. The NEW statement then actually creates the object at runtime and makes its fields and methods available for use.

This use of NEW is an extension of the standard Pascal NEW procedure. The compiler recognizes that we’re creating an object and not a standard data structure by the type of the variable that we’re NEWing, in this case aKlingonVessel.

Once we’ve created our object, its data fields become accessible. The statement

 aKlingonVessel.fNumTorpedoes := 10;

initializes the field fNumTorpedoes; prior to this statement, the value of the field was undefined. Note again the RECORD-like syntax used here. Only this time, we’re working with a variable and not an object type: note that the prefix, or qualifier, is changed accordingly.

Finally, we can execute the code of our launch procedure with the statement:

 aKlingonVessel.LaunchTorpedoes;

This creation of a new object is known as instantiation, a wonderful term; we have created an instance of this object type. Its data fields are now stuffable; its code is now executable.

To confuse matters just a bit (just when you thought you were getting things under control): the variable aKlingonVessel is not the object itself. Close, but no cigar. The variable aKlingonVessel is an object reference variable, or simply an object reference. Why?

The relationship between an object reference variable and an object is very similar to that between a handle and the handled block it points to. An object actually is a handled block, but with a few important differences from our standard understanding of the term. It floats on the heap, just like a normal handled block, and is just large enough to contain space for its data fields and code (well, almost). The handle itself, or more properly the object reference variable, is exactly four bytes long, as you’d expect for a handle.

OK, I was bending the truth - our object doesn’t actually contain the code for its methods, as I’ve stated. Rather, it contains a pointer that points to where the code actually resides in memory (and who knows, or cares where that is?). That’s why I said earlier that my statement about creating code on the fly at runtime is somewhat inaccurate - the code is already there; we just create the object that contains the pointer to it. Ken Doyle gave a good description of the method-table mechanism that handles this in the December ’86 issue of MacTutor (saving me from having to explain an implementation issue that I don’t fully understand anyway).

Syntactically, while an object-reference variable such as aKlingonVessel acts much like a handle, notice that we don’t have to use Pascal’s caret symbol to dereference it in order to get at the fields of the object it points to. The period separator is sufficient.

There’s one other interesting thing to look at. When we make the statement:

aKlingonVessel.LaunchTorpedoes,

we might say that we’re invoking this method from outside the object. But once that method begins to execute, we are, in a sense, inside the object. I’m talking here about the subsequent code that gets executed by the above line:

IF fNumTorpedoes > 0 THEN BEGIN
 fNumTorpedoes := fNumTorpedoes - 1;
 DoLaunch;
...

Notice, since we’re now on the inside looking out, that we needn’t qualify the fieldname fNumTorpedoes with the name of the object, aKlingonVessel, or the typename, TKlingonVessel. Either, in fact, would be an error. And here’s one place where naming conventions are useful: the “f” in “fNumTorpedoes” immediately tells us that this is a field belonging to our object, and not something else such as a global variable (in which case it would probably start with a “g,” again by convention). What’s important is that any of the data fields belonging to this object are accessible from within any of its methods, as long as the object exists. This is an extension of Standard Pascal’s scoping rules and has important consequences which we’ll look at later.

The matter of DoLaunch is slightly more involved. Since we’re inside a Klingon vessel object, DoLaunch might be the name of another method belonging to type KlingonVessel (that I haven’t shown), or it might be the name of a standard Pascal procedure that’s not a method at all. Again, once we’re inside an object and executing one of its methods, any other methods that we invoke that belong to that object are not qualified. Finally, there’s a minor variation on the first possibility that we’ll cover when we look at the subject of inheritance.

OK, we’ve now got Klingon vessel objects. More precisely, we’ve got one Klingon vessel object. This represents one ship. In a real Star Trek game, we would probably expect to find numerous Klingons, and there’s nothing to stop us from creating other objects of the same TKlingonVessel type. For example:

VAR
 aKlingon1:  TKlingonVessel;
 aKlingon2:  TKlingonVessel;
BEGIN
 NEW( aKlingon1 );
 aKlingon1.fNumTorpedoes := 10;
 aKlingon1.LaunchTorpedoes;
 NEW( aKlingon2 );
 aKlingon2.fNumTorpedoes := 30;
 aKlingon2.LaunchTorpedoes;
 ...

Now we’ve got two Klingon vessel objects floating in quadrant four, as well as in the heap. They share the same code (there are two pointers to the single method, LaunchTorpedoes), but it’s important to note that they each exist independently of the other one. In particular, their data fields are unique. This shouldn’t be a big surprise if you think about creating two RECORD variables in Pascal that are both based on the same type definition.

At the end of the above sequence of statements, aKlingon1 has 9 torpedoes left, and aKlingon2 has 29 torpedoes remaining.

OK, we’ve now got Klingon objects galore, one for every Klingon vessel in our game. Let’s back up a bit and put the above piece of code in context. The question is: where are these Klingons being created? In other words, who is creating them? Somebody has that responsibility.

In a typical game, we’ll probably have another object whose job it is to mind the board and keep track of turns and other things like that. We might call this the game object and declare it to be of type TGame. Our TGame object will also be responsible for creating all the vessels that are going to appear during the course of the game. This sequence of events (non-Macintosh usage here) is highly typical of the way most object-oriented programs behave at runtime: we initially instantiate one object; it in turn instantiates another; and so on down the line. (If you’re astute, you might well ask at this point what happens if we just keep on instantiating objects, knowing that every instantiation creates a new block in the heap. A very good question. Don’t ask; I’ll come back to this later).

In any event, if we go back and expand the above piece of code just a bit, it’ll look something like this:

{ IMPLEMENTATION }

TGame.NewVessel;
VAR
 aKlingon1:  TKlingonVessel;
 aKlingon2:  TKlingonVessel;
BEGIN
 NEW( aKlingon1 );
 aKlingon1.fNumTorpedoes := 10;
 aKlingon1.LaunchTorpedoes;
 NEW( aKlingon2 );
 aKlingon2.fNumTorpedoes := 30;
 aKlingon2.LaunchTorpedoes;
 ... { other stuff }
END;  { TGame.NewVessel }

All I’ve really done is bracket the code we saw earlier between the name of the game method and an END statement. Again, we’re being somewhat unrealistic for the sake of pedagogy. It’s much more likely that this NewVessel method of our game object would be used to create one Klingon, and not two, at a time, and that we’d invoke it whenever we wanted to create a new one (as indicated by a menu or dialog selection, or whatever). Since these objects differ only in the number of torpedoes we initialize them with (at least according to the limited context I’m showing here), we’d probably pass in a parameter like NumTorpedoes that immediately gets stuffed into the fNumTorpedoes field. In other words:

TGame.NewVessel( NumTorpedoes : INTEGER );
VAR
 aKlingon :  TKlingonVessel;
BEGIN
 NEW( aKlingon );
 aKlingon.fNumTorpedoes := NumTorpedoes;
 aKlingon.LaunchTorpedoes;
 ... { other stuff }
END;  { TGame.NewVessel }

To be able to keep track of individual Klingons, the TKlingonVessel type would also probably have a field called fID, and we’d increment this field by one for each new ship we added so that each Klingon had a unique number.

Rather than initializing our objects exactly as I’ve shown above, however, it’s a much more common practise to provide each object with its own initialization method, and pass our parameters to the method to let the object initialize its own fields. This occurs throughout MacApp. To wit:

NEW( aKlingon );
aKlingon.IKlingonVessel( NumTorpedoes );
aKlingon.LaunchTorpedoes;

and

TKlingonVessel.IKlingonVessel( NumTorpedoes:INTEGER);
 BEGIN
 fNumTorpedoes := NumTorpedoes;
 ... { other initialization stuff }

What can we say about the name of the method, IKlingonVessel? Again, simply a matter of convention, in which an “I” (obviously standing for “Init”) is prefixed to the object name. OK, that’s a long digression. The main reason I’ve shown the above code is to pose one further query (I love doing that; can’t you tell?).

The question is this: once the delimiting END statement is reached in the NewVessel method, what happens to the objects that were created there? Well, in a word: nothing. They continue to exist in the heap, but there’s no longer any way to reference their fields or methods from outside them. The only way we had of doing so within the NewVessel block was to use our reference variable, aKlingonVessel (or aKlingon1 or aKlingon2, as appropriate). Pascal’s scoping rules say that these variables are local to the method and cease to be once the block is exited. This is a problem, since our game object is likely to want to communicate with them later on.

The answer is to realize again that an object-reference variable is just that: a variable. And the value of a variable is a perfectly good candidate for sticking into one of the data fields of our game object via a Pascal assignment statement. That way, since the fields of the object continue to exist as long as the object itself exists, we’ll be able to get at any “subordinate” objects that are referenced there at any time we like. First, we’ll have to add the necessary reference field to our TGame TYPE declaration:

TYPE
 TGame = OBJECT
 fTheKlingon :  TKlingon;
 ...    { other relevant fields }
 PROCEDURE TGame.NewVessel;
 ...  { other relevant methods }
 END;  { TGame object type }

We can then do the following simple assignment in our TGame.NewVessel method:

TGame.NewVessel;
VAR
 aKlingonVessel :  TKlingonVessel;
BEGIN
 NEW( aKlingonVessel );
 fTheKlingon := aKlingonVessel; { <<-- }
 aKlingonVessel.fNumTorpedoes := 10;
 { or fTheKlingon.fNumTorpedoes := 10 }
 { ... etc. }

That’s it! We’ve now established a communcation link, if you will, between our game object and this particular Klingon vessel. No matter what other method of the game object may be executing later on, the game will be able request this Klingon to launch torpedoes or perform any of its other methods by using the fTheKlingon reference field. The syntax for doing so, by the way, is almost identical to what we’ve already seen. For example, if Klingons have a method that allows them to fire a phaser bank (I don’t even know if Klingons have phaser banks!), the game object can request one to do so simply by saying

fTheKlingon.FirePhasers;

We can even extend this usage into stranger realms. If our Klingon type has a method that allows it to scan neighboring quadrants for enemy warships and report their location, the game object can ask it to do so by saying

EnemyPosit := fTheKlingon.ReportEnemyPosit;

This is an example of a method that’s actually a function, rather than a procedure. This construct might seem somewhat strange if you haven’t encountered it before. I remember when I was reading the documentation and seeing constructs like this for the first time; there was a lot of head scratching. Hopefully, you’re not as slow as I was.

I’m going to leave it at that for the moment. There is a lot more. And we haven’t even talked about inheritance, overriding, SELF, or a number of other object-oriented subjects. Stay tuned next issue for Romulans, Vulcans, and the other denizens of deep space. Get objective.