|Column Tag:||Developer's Forum
By Paul Snively, Contributing Editor, Wheeling, IL
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. Thats 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 doesnt mean that the picture is bleak. Far from it. Let me explain:
Theres a cube sitting about ten feet away from me. I wont bore you with digitized pictures or a gushing description of how sexy it is; weve all seen the pictures, and we all know how sexy basic black can be (a fact thats never been lost on the fashion world). The fact of the matter is that there are probably a fair number of people in MacTutors 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. Theres 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 werent are now, after just two paragraphs of my lurid prose, so Id 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 (its Carnegie-Mellons 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 isnt entirely NeXTs; it was jointly developed with Steve Jobs other little company, Pixar. By the way, if Pixar isnt doing a chipset/card for the NeXT computer thatll turn it into one of the hottest graphic workstations around, Ill 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 Foundations gcc (the GNU C compiler), gdb (GNU C source-level debugger), and GNU EMACS (as well as the Berkeley standard vi editor and NeXTs own Edit, which is--as you might have guessed--a simple multi-window text editor based on NeXTs windowing system, Display Postscript, etc.)
It doesnt stop there. Each and every machine includes the Application Toolkit. The only way that I can describe the AppKit, as its called by NeXT, is that its what MacApp should have been. Again, this is nothing radical or new; its 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 its 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 wouldnt think that the Interface Builder is anything special. In fact, it sounds an awful lot like ResEdit, doesnt 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 youd expect--by dragging buttons, sliders, fields, etc. to a window--but once youve 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 isnt 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, lets 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 well title >>Convert>> to highlight the fact that were 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 applications 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 isnt a user-interface object--its 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 Converters 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 shouldnt--and dont--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.)
Its unfortunate that I cant include NeXT screen dumps in this article; this whole process requires far too much verbiage to describe. Everything Ive 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 wont go into massive details of the syntax and concepts behind Objective-C here, partially because this isnt 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 doesnt 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];
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 hasnt anyone done anything like that for MacApp? Certainly parsing and generating Object Pascal code with some amount of inside knowledge of MacApp shouldnt be that tough; anyone whos ever used compiler-development tools such as yacc and lex knows that. Lets not let this piece of evolution pass us by. With tools like this, programming can become much easier for all of us.