Volume Number: 13 (1997)
Issue Number: 7
Column Tag: Getting Started

Getting to know NEXTSTEP

by Dave Mark, ©1997, All Rights Reserved

Do you remember the very first time you sat down at a Macintosh? For me, it was almost a religious experience. I instantly connected to the interface, to the elegance of the Mac look-and-feel. Recently, I've had the opportunity to explore some of the other major operating systems out there, including, most recently, NEXTSTEP. I must say I was both surprised and impressed.

Why spend time with NEXTSTEP? As you know, Apple bought NeXT with the intention of basing their next OS, Rhapsody, on the NEXTSTEP technology. By the time you read this, Apple should be putting the finishing touches on a preliminary release of Rhapsody. Till then, NEXTSTEP is the closest thing I have to Rhapsody. Also, I think it is worthwhile exploring the roots of our new OS, to get a sense of the logic behind some of the Rhapsody design decisions.

NEXTSTEP is both nice looking and easy to use. Though I did have trouble installing the developer's release on my PC, once it was up and running I found NEXTSTEP to be solid and a joy to use. This month, we'll take a first look at NEXTSTEP and the process of building a console Objective-C app. We'll also look at Objective-C's category mechanism, a cool way of seamlessly extending an existing class.

This month's column owes a debt of gratitude to CodeWarrior Gene Backlin. Gene wrote the book Developing NEXTSTEP Applications (ISBN# 06723-06581) and helped me come up to speed on the NEXTSTEP interface and the Project Builder and Interface Builder applications. Thanks, Gene!

And thanks also to Michael Rutman for his monthly expert tech review. As always, the mistakes are all mine...

One of the first things you'll notice when you boot up under NEXTSTEP is the "dock" that appears in the upper-right corner of your screen. My dock is shown in Figure 1. Each square in the doc represents an NEXTSTEP application. The NeXT cube at the top of the doc represents the NEXTSTEP equivalent of the Finder, called the FileViewer. Below that is the preferences application (which I've set to show the time and date). The last three squares are a terminal emulator which you can use to run your console apps, and the two programs which make up the NEXTSTEP development environment, Project Builder (the hammer) and Interface Builder (the screwdriver). We'll use the terminal emulator to build this month's apps, and move on to Project Builder and Interface Builder next month.

Figure 1. The NEXTSTEP "dock". By default, it appears in the upper right corner of the NEXTSTEP screen.

To launch an app from the dock, double-click on its square. If the app is already running, a double-click will bring it to the foreground, just like a Mac. You can tell if an app is not running by the elipsis (...) in the lower right corner of its dock square (i.e., no ellipsis means the app is running).

In general, you'll use the File Viewer to wander around your hard drive. As you can see in Figure 2, the File Viewer window is divided into three areas. The top area is for mounted volumes and aliases. The central strip shows where you are currently. In this case, we are looking at the directory /myhost/me. The bottom area shows the files and folders in the current directory. In this case, the directory /myhost/me contains 4 folders and 0 files.

Figure 2. The File Viewer window, showing the files in the default, "me" directory.

Notice the apple icon in the floppy disk in the top line? Yup. I stuck a Mac floppy in the PC floppy drive and NEXTSTEP recognized it. Very cool! That's how I was able to get my source code and screen shots (shot with the Grab application) over to my Mac. There's something nice about being able to work with a Mac floppy on my PC...

Figure 3 shows a pair of menu windows. The left window (labeled Workspace) holds the main File Viewer menu. The right window (labeled View) appeared when I clicked on the View item in the Workspace menu. Menus and submenus. Like a Mac, but different. Menu items can have command-key equivalents, but since this version of NEXTSTEP was running on my PC, they were Alt key equivalents. In general, NEXTSTEP feels like it borrowed heavily from the Mac (and why not?). If you are not sure how to do something, think about how you'd do it on a Mac. For example, Alt-c and Alt-v copy and paste, Alt-q quits, and Alt-w closes the frontmost window. Sound familiar?

Figure 3. The Workspace menu and View submenu.

NEXTSTEP allows you to remap the keyboard. By default, on an Intel box, the left Alt-Key is mapped to be a command key. There are several different configurations built in, and you can create your own.

Figure 4 shows the File Viewer with the Browser View selected. The NeXT browser is a truly nice way to navigate your file system. I hope this part of the NEXTSTEP interface makes it into Rhapsody. Note that as you descend into a directory, the path is reflected in the middle strip, while the details at each level are displayed in the browser portion at the bottom of the File Viewer window. In Figure 4, we are looking at the shapes directory, which holds the files from last month's sample program.

Figure 4. The File Viewer, with the Browser view.

As I brought my source code over from my Mac (where I was running CodeBuilder), I learned a few important lessons. First, try to avoid spaces in your file names. If you include a space in a file or directory name, you'll create a lot of extra work (and potential hair pulling) for yourself as you add escaped quotes to your makefiles, etc. to make sure the spaces are kept in the names. Save yourself the trouble and leave the spaces out.

I'm not sure of the details, but I've found that some odd (invisible) characters creep into my code when porting from Mac to NEXTSTEP. This could be a result of carriage return/line feeds being treated differently on the two platforms, or an artifact caused by my method of porting the files across. Regardless, if you find a line of code that looks perfect, yet behaves oddly, make sure that your files are true Unix files. If you create them in CodeWarrior or BBEdit, or on the NeXT box, this shouldn't be a problem. If you created your file on another platform (like your Mac), the mechanism you used to move the file to your NeXT box should handle the translation for you.

If all else fails, you might try translating your source file using the command:

tr '\015' '\012' < sourceFile > newFile

Another lesson learned is that different versions of OPENSTEP and NEXTSTEP look and behave quite differently from each other and from Tenon's CodeBuilder environment. For example, CodeBuilder doesn't support #import (at least not in the same way as NEXTSTEP). Under CodeBuilder, I had to use a #ifndef to avoid recursve inclusion of my header files. Moving to a genuine NEXTSTEP environment was really nice.

There are other differences as well. CodeBuilder calls gcc gcc, while under NEXTSTEP, gcc is called cc. This requires a small change in the makefiles. Also, NEXTSTEP automatically includes the Objective-C library in its standard libraries, so there is one less library to include. Here's the makefile I used when I moved Shape over to NEXTSTEP:

Shape:  Main.m Shape.m Circle.m Cylinder.m
  cc -o Shape Main.m Shape.m Circle.m Cylinder.m

Note the use of cc instead of gcc as well as the absence of the link library. Figure 5 shows the result, running in a terminal emulator window. Once we move into Project Builder and Interface Builder (next month's column) you can say goodbye to all this console business.

Figure 5. Running last month's Shape application inside the terminal emulator.

Objective-C features a mechanism known as a category that allows you to extend an existing class without modifying the .m and .h file of the original class. Why would you want to do that? The most obvious reason would be to extend a class when you don't have access to the source that defines the class. But there are other reasons to use a category to extend a class. You might want to organize your class into related subgroups. This is especially useful if you are building an extremely large class (you can take advantage of incremental compilation) or if your class is being worked on by more than one person. You might also use categories to extend a class in different ways for different applications.

To implement a category, you'll define a set of methods placing the interface in a header file and the implementation in a .m file. You can use a category to add methods to a class, but you are not allowed to use a category to add any variables to the class. A category method can override an inherited method and can get at the inherited method by sending a message to super. But a category method has no way to call a method in the original class having the same name as the category method (i.e., don't create a category method with the same name as a method in the class being extended).

An example should help make this clear. If you remember, last month's example implemented 3 classes: Shape, Circle, and Cylinder. Shape is derived from Object, Circle from Shape, and Cylinder from Circle. Without modifying the Shape, Circle, or Cylinder classes, we'll extend the Circle class and access the new methods from a Cylinder object. We'll call the category CircleMath. It will add an area and circumference method to the Circle class.

Here's the source code for CircleMath.h:

#import "Circle.h"

@interface Circle (CircleMath)
- (float)area;
- (float)circumference;
@end

Here's the source code for CircleMath.m:

#import "CircleMath.h"


@implementation Circle (CircleMath)

- (float)area

{

  return ((float)radius * (float)radius * 3.14159);
}

- (float)circumference
{
  return ((float)radius * 2.0 * 3.14159);
}

@end

Here's the new version of Main.m. We've added a #include of CircleMath.h as well as a pair of printf()s. The first printf() sends an area message to cylinder and the second printf() sends a circumference message to cylinder.

#include "Cylinder.h"
#include "CircleMath.h"

void main()
{
  id shape = [[Shape alloc] init];
  id circle = [[Circle alloc] initRadius:33];
  id cylinder = [[Cylinder alloc] initRadius:27 
height:10];

  printf( "\n[cylinder area] = %f...\n",
          [cylinder area] );
  printf( "[cylinder circumference] = %f...\n",
          [cylinder circumference] );

  [shape free];
  [circle free];
  [cylinder free];
}

Finally, here's the make file I used:

Shape:	Main.m Shape.m Circle.m CircleMath.m Cylinder.m
cc -o Shape Main.m Shape.m Circle.m CircleMath.m Cylinder.m

Note that I added the file CircleMath.m to both lines. That's it. Figure 6 shows the output when I ran this new version of Shape.

Figure 6. Running Shape with the CircleMath category added in.

I am very jazzed about NEXTSTEP and the promise it holds for Rhapsody. I can't wait to get to WWDC (a few weeks from now) and find out about what portions of the NEXTSTEP framework will make their way into Rhapsody. Till then, we'll continue to expore NEXTSTEP and, perhaps, make a return to Java as well. Got an opinion? Drop me a line...