NeXT Evolution
Volume Number: 5
Issue Number: 7
Column Tag: Developer's Forum
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 pr events 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.