NeXT Evolution

By Paul Snively, Contributing Editor, Wheeling, IL

Evolution

Those of you who are waiting for the next (NeXT?) revolution in microcomputing are likely to be disappointed lately, and are probably going to remain that way for some time to come. That’s the news that I have to offer now that I have access to a NeXT computer. Before you go jumping out of your office windows or selling off your worldly goods and waiting for the end of the world to arrive, let me quickly add that this doesn’t mean that the picture is bleak. Far from it. Let me explain:

There’s a cube sitting about ten feet away from me. I won’t bore you with digitized pictures or a gushing description of how sexy it is; we’ve all seen the pictures, and we all know how sexy basic black can be (a fact that’s never been lost on the fashion world). The fact of the matter is that there are probably a fair number of people in MacTutor’s readership who remain without hands-on experience with this particular cube and would like some ideas from a fellow Macintosh developer as to just what this enigmatic little machine is like.

This Baby Ain't Portable!

For starters, the machine is, well, enigmatic. If you ever have to carry one of these things, the first thing that you realize is that the MegaPixel display that ships standard with every machine is far, far heavier than the computer itself is. Aside from that, there are virtually no physical problems with the machine. Putting one together is a simple matter of plugging the keyboard and mouse into the monitor, running a large cable between the computer and the monitor, and plugging the computer into the wall. Oh, by the way, you can plug the computer into the wall in the United States, England, Germany, or most other European countries with equal facility and no converters necessary.

25 mHz 68030 Processor

The computer itself, from an internal standpoint, is something of a throwback to a bygone era, at least in the microcomputer world: the case is simply a card cage. It consists of a power supply, an optical disk drive, optionally an internal Winchester hard disk, and a single card that literally can be described as the motherboard. The motherboard contains the obvious things: a 25 mHz MC68030 microprocessor, a similarly-clocked MC68882 floating-point coprocessor, and the by-now-famous Motorola DSP (Digital Signal Processor) chip. There are also two rather large custom VLSI chips that provide the I/O throughput that NeXT is so proud of. There’s also on-board Ethernet support for the thin-wire connector that sits on the backplane of every machine (and you thought AppleTalk on every machine was something).

Most of us are at least in touch with the hardware specs for the machine, and those who weren’t are now, after just two paragraphs of my lurid prose, so I’d better get to the point, which is this: the NeXT computer is a very nice 68030-based low-end workstation that supports a very nice version of UNIX (it’s Carnegie-Mellon’s MACH operating system, which consists of a rather small, tight kernel that provides a few new wrinkles in terms of memory management, networking, and multiprocessing, but manages to be compatible at the OS call level, not just the user level, with BSD4.3 UNIX). On top of MACH is Display Postscript, with a few NeXT wrinkles, such as fast bitmap compositing, thrown in for good measure (actually, even bitmap compositing isn’t entirely NeXT’s; it was jointly developed with Steve Jobs’ other little company, Pixar. By the way, if Pixar isn’t doing a chipset/card for the NeXT computer that’ll turn it into one of the hottest graphic workstations around, I’ll eat my shirt).

Ok, so we have what, from almost all outside appearances, is a 68030-based UNIX box running Display Postscript. Now what?

An Object-Oriented Computer From Ground Up!

“Now what” is what this article is really about. Because the reason that the NeXT computer is a piece of evolution that we should all be paying attention to as developers has nothing to do with the 68030, with the DSP, with optical storage, with UNIX or MACH, or any of that. It comes down to this:

The NeXT computer is an object-oriented computer almost from the ground up. Every machine ships with Stepstone, Inc.’s Objective-C, and the Free Software Foundation’s gcc (the GNU C compiler), gdb (GNU C source-level debugger), and GNU EMACS (as well as the Berkeley standard vi editor and NeXT’s own “Edit,” which is--as you might have guessed--a simple multi-window text editor based on NeXT’s windowing system, Display Postscript, etc.)

It doesn’t stop there. Each and every machine includes the Application Toolkit. The only way that I can describe the AppKit, as it’s called by NeXT, is that it’s what MacApp should have been. Again, this is nothing radical or new; it’s just the NeXT evolutionary step along the road that MacApp paved. The AppKit has a relatively small number of classes, and the hierarchy is fairly straightforward. The AppKit does what the AppKit should do: it makes the process of writing a NeXT application as painless as programming such a machine should be.

The reason that it’s so painless, however, is only partially a function of using Objective-C and the AppKit. The other important element in the development-tool arena is the Interface Builder.

Now, judging from the name alone, you wouldn’t think that the Interface Builder is anything special. In fact, it sounds an awful lot like ResEdit, doesn’t it? After all, ResEdit is a nice interactive utility for creating things that are, by and large, human interface elements, such as windows, dialog boxes, menus, strings, string lists, and the like. Certainly Interface Builder does all of these things, but more importantly, Interface Builder has some smarts about Objective-C and the AppKit. You can build dialogs in Interface Builder in the way you’d expect--by dragging buttons, sliders, fields, etc. to a window--but once you’ve done that, you can go a step or two further.

Interface Builder knows about objects that are part of the AppKit. It knows that applications have a main window and a main menu. It knows that there may be other windows, and submenus attached to the main menu. It knows about the standard behaviors that the AppKit defines for these objects (for example, it knows that when you click a button, the button should send some message to an object).

Non-human-interface objects--any object that isn’t part of the AppKit, in fact--Interface Builder knows nothing about by default. However, you can specify any custom object to Interface Builder, describing its methods in just enough detail to allow Interface Builder to use them in the process of connecting things.

To use a trivial example, let’s convert degrees Celsius to degrees Fahrenheit. To do this, we probably want a dialog that contains two text fields, Celsius and Fahrenheit, and a button, which we’ll title “>>Convert>>” to highlight the fact that we’re converting from Celsius to Fahrenheit.

All that we have to do to create this dialog is to drag two text fields and a button to our application’s main window. We should lay things out appropriately and label the fields and button appropriately. Then what we need to do is define a custom object, called “Converter,” to the Interface Builder. Converter isn’t a user-interface object--it’s the object that actually does the computation. It will only have one method, “convert,” which will take zero parameters, and it will have two “outlets,” input and output.

Outlets are the means by which non-user-interface objects communicate with user-interface objects. An outlet is an instance variable that an object possesses that gets initialized to the id of some other object so that the object owning the outlet can send messages to the other object. In this case, we will use the Interface Builder to connect the Celsius field to the Input outlet and the Fahrenheit field to the Output outlet. This way Converter’s convert method can refer to Input and Output to do the job without worrying about exactly what the objects being referred to are--Input could, after all, be connected to some object that provides a C-language-style float value based on a signal from an A/D converter attached to some sensor somewhere. Converter and its convert method shouldn’t--and don’t--care.

By now you may be wondering how all these connections are made. The Interface Builder includes a Connect panel that has square recessions to contain the sender object, the receiver object, and the outlet object. There are also two scrolling fields above the recessions. First, you would drag the button object to the sender recession and the Converter object to the receiver recession. The left-most scrolling text field would then list all of the messages that the Converter understand. We defined it to only understand one, convert. Clicking on that line in the scrolling field will cause a cable to appear between the button object and the Converter object, with separated screw and tab connectors in between. Clicking the cable closes the connection, indicating that clicking the button will send the convert message to the Converter object.

The right-most scrolling text field will list the outlets for the Converter object. Again, we defined two, Input and Output. We would drag the Celsius field to the outlet recession, then click on the line showing Input. A cable with separated male and female connectors would appear between the Converter object and the Celsius field. Clicking the cable would indicate that we want the Input instance variable initialized to refer to the Celsius text field in our dialog. We would repeat the process for the Fahrenheit field, connecting it to the Output outlet (read “instance variable.”)

It’s unfortunate that I can’t include NeXT screen dumps in this article; this whole process requires far too much verbiage to describe. Everything I’ve discussed so far can be done in Interface Builder in considerably less than sixty seconds. All that remains, then, is to save your work in Interface Builder and actually sit down and write the code for the Converter object.

I won’t go into massive details of the syntax and concepts behind Objective-C here, partially because this isn’t the time or place, and partially because my understanding of both is extremely incomplete at this point. In any case, the process consists of creating a new class, Converter, that will simply be a subclass of Object, since it doesn’t need to inherit anything special from anything else. Converter would have two instance variables, Input and Output, both of type id (all objects in Objective-C are of type id). We would then define the single method, convert. Convert will have two local variables of type float, c and f. The code for convert would then look something like this:

c = [Input getFloatValue];
f = (c *9.0 / 5.0) + 32.0;
[Output setFloatValue: f];
return(self);

Apart from declaring the class and its instance variables and the method and its local variables, that is all there is to converting from celsius to fahrenheit at literally the click of a button. The Interface Builder prevents you from having to write any more code than that to make your application work.

The question I have is this: why hasn’t anyone done anything like that for MacApp? Certainly parsing and generating Object Pascal code with some amount of “inside knowledge” of MacApp shouldn’t be that tough; anyone who’s ever used compiler-development tools such as yacc and lex knows that. Let’s not let this piece of evolution pass us by. With tools like this, programming can become much easier for all of us.