MacApp 3 will add large amounts of spice to programming recipes. There are new classes, new twists on old classes, and new hoops to jump through.
However, the more interesting items are from the primary language of implementation changing from Pascal to C++. In fact, I propose that MacApp 3's best features are its solutions to the so-called "Nested Procedure" problem.
As a software author, I spend a fair amount of time listening to a short description of some problem a user is having and a longer description of what the user wants to do to solve it. Sound familiar? Sometimes the user is right on the money as to the nature of the "right" solution, but more often it is their description of the problem that is most revealing. I view the Nested Procedure problem in that light. I don't necessarily want nested procedural constructs, but I do have a problem to solve.
One solution is to implement language support for grouping sets of code in some logical order. The Pascal language provides this. However, it's not the only solution, nor is it the only solution for the MacApp programmer-at least not for the ones who use C++.
This article will examine the nested procedure problem, look for solutions, and discuss what this has to do with MacApp. First, I'll describe the problem in more detail. This may seem obvious and repetitive, but the goal is to come up with something that does what nested procedures in Pascal do. In addition, the solution should be link compatible with Object Pascal.
Simply put, a scope is the range over which a coding entity-variable, constant, or routine-is meaningful. Languages like assembly generally recognize only one scope, global. That is, once you get down to the assembly level, everything is visible to everyone all the time.
Moving up one step, there is C. C recognizes two basic scopes, global and local. That is, something is either scopeless-global-or it exists within a specific routine.
Languages like Pascal maintain a highly ordered, scoped hierarchy. Pascal's description of scoping is so good, in fact, that to many people, Pascal's implementation is scoping.
Probably not, but you do have to be careful. For example, many of you may remember something like the code in Listing 1 from a Computer Science 101 test. The exam would quiz you on the output of the program; to answer correctly, you would have to recognize that there are overlapping scopes and resolve them appropriately.
In a more practical world, you might see something like Example 2. Example 2 calls a procedure, DoSomethingToIntegers, telling it what action it wants performed, namely DoToInteger. Furthermore, DoToInteger has some magic knowledge of the local variables, oneInt and twoInt. Pascal accomplishes this by giving the nested procedure, DoToInteger, an additional parameter referred to as a "static link" variable. The static link is a pointer to the stack frame of the enclosing routine.
Thus, when a Pascal nested procedure is called, a pointer to the routine's stack frame is passed as a hidden argument. Also, when a routine is passed as a procedure parameter to a Pascal routine, as is done with DoToInteger, a pointer to the routine's stack frame is passed as an additional parameter. In the example, DoSomethingToIntegers actually takes two parameters, the routine to execute, DoToInteger, and a value to pass as the static link parameter to the indicated routine.
In Example 3, you could just pass DoSomethingToIntegers a pointer to oneInt, and have CBasedDoToInteger know that staticLink is a pointer to a short, namely oneInt. But that means it won't know about twoInt! Alternatively, you could define a structure that holds oneInt and twoInt, and pass a pointer to the structure for the static link, but that's unattractive. Clearly, it's better to refine and generalize the solution.
The key to an object-based approach is to recognize that, implicitly, a method is scoped to exist within an instance of an object. I tend to avoid hard-core C++ documentation (except during psychotically masochistic episodes), but in most C++ texts, the descriptions of objects as scopes-and the implications of this for visualizing program constructs-are very good.
For the problem above, a class could be defined, like CDoToInteger in Example 4, to handle the hard work. CDoToInteger looks much closer to what's desired than CBasedDoToInteger in Example 3.
"But where did the mystical staticLink parameter go?" the intrepid reader asks. It's hidden by the magic of object programming, just as it was hidden by the magic of Pascal in the Pascal example. In the object programming case, the scope is determined by the implicit variable this (SELF for you Pascal fans, Current for you Eiffel fans).
Look again at CPlusFoo in Example 4 to see how the CDoToInteger class might be used. I've indicated a routine to invoke-CPlusDoToInteger in the scope of CDoToInteger-and indicated a context in which to execute the routine, aScope. That's it, right?
Not quite. I still have to find some way for aScope to know about oneInt and twoInt within CPlusFoo. One solution might be to set the individual instance variables of aScope to hold the same values as the local variables of CPlusFoo, but that's not what I really want. I want the oneInt and twoInt variables of CDoToInteger to be pointers to oneInt and twoInt in CPlusFoo, but I also need to ensure that those pointers are never nil.
This is the second and last reason that to reasonably use reference variables in C++ MacApp code. (The first involved parameter passing, and was discussed last issue.) So, the CDoToInteger class is finished in Example 5. The careful reader will notice that the declaration of CPlusDoToInteger changed subtly in this last revision. It now carries a Pascal calling sequence, so that it's compatible with Pascal. The difference here is the order in which parameters on the stack are evaluated. The declaration above indicates that the magic this parameter is to be the last parameter pushed on the stack, just like the Pascal magic static link is pushed on last. Ta da.
class CCountSubViews {
private:
long& numberOfViews;
public:
CCountSubViews(long& aNumberOfViews) :
numberOfViews(aNumberOfViews) { }
pascal void CountSubViews(TView* aView)
{
numberOfViews++;
}
};
pascal void TMyView::CountSubViews()
{
long numberOfSubViews;
CCountSubViews aCounter(numberOfSubViews);
fSubViews->Each(CCountSubViews::CountSubViews,
&aCounter);
}
You can come up with more relevant examples, I'm sure, but I chose this particular example for a reason. Each is a method that allows a routine to iterate over the items in a TList. This can be used with the magic of Pascal and nested procedures; however, MacApp 3 provides C++ users with another way to iterate.
// Find the sum of all integers on the interval [0..4]
short a;
a = 0;
for (short i = 0; i < 5; i = i + 1)
{
a = a + i;
}
MacApp 3 provides a nice mechanism for doing this-iterators. A library of iterator objects (sorry, C++ users only) is available for doing a variety of iterative actions. The following is an example of CObjectIterator, the class for iterating over objects in a TList:
CObjectIterator iter(aTList);
for (TObject* anOb = iter.FirstObject(); iter.More();
anOb = iter.NextObject())
{
// do something with anOb here
}
Within the body of the loop, you can manipulate anOb just as you would any local variable. The reason for this is that anOb is a full-fledged local variable. So, if you happen to know that aTList only contains instances of TFoo, you can easily (and legally) cast anOb to TFoo*.
Iterator classes are provided for most of the basic iterations. For example, the CSubViewIterator class, iterates over each subview of a given TView. You might use it in the following fashion:
CSubViewIterator iter(aTView);
for (TView* aView = iter.FirstSubView(); iter.More(); aView = iter.NextSubView())
{
// do something with aView here
}
