"Object Oriented Programming"

By Noel J. Bergman, Software Engineer, MCTel, Inc., MacTutor Contributing Editor

This is the first of a new column object oriented programming. The intent of this first column is to lay the groundwork for object oriented programm-ing, and to review the first object oriented language for the Macintosh, NEON from Kriya. In future columns, we will be using NEON to explore object oriented programming, possibly with short side trips to examine other object oriented languages, if and when they appear.

Why object oriented programming?

As you are all undoubtedly aware, programming the Macintosh is not very easy for most programmers. It is difficult not only for the non-professional programmer: many professionals are having a great deal of trouble dealing with the Macintosh. Most, if not all, of the real problems in dealing with the Macintosh come from the fact that the programs are non-modal. Solutions, such as finite state automata theory, are not well known and produce artificial program constructs. A much better solution is to use object oriented programming.

Historical Perspective

Apple got many of its ideas from the Xerox PARC Smalltalk research group headed by Alan Kay. In fact, a number of that project's members, including Kay himself, are now at Apple. Alan Kay's greatest vision may have been in programming philosophy, or methodology. The wonderful user interface envisioned by the PARC group required a new programming methodology to bring it to life. The one they developed, object oriented programming, has influenced every major language developed since that time, most noticably Smalltalk, Ada and Modula-2.

Although a few computer scientists have been aware of, and applying, object oriented programming for years, the Macintosh has brought home to Apple and thousands of other programmers, the necessity of teaching and learning these techniques.

What is Object Oriented programming?

By now, you are probably wondering what object oriented programming means. What it means is that you define classes of objects, and methods that act upon them. You declare objects to be of a certain class and act upon them by using the methods provided. No access to their internal structure is permitted. You create subclasses, which inherit their storage and methods from their superclass, and may provide additional local storage and methods that add to or replace those inherited from their superclass . A concrete example of this is the Macintosh window, which is a subclass of a QuickDraw grafport, and has additional fields and methods.

This technique allows us to start with a generic application, and to add the subclasses and methods to implement our own unique application.

In a true object oriented programming language, applications are written by creating objects that communicate by sending messages to other objects. This message routing mechanism provides us with the power we need to deal with the Macintosh. The objects remember what has happened to them, and what their status is. We send them messages telling them of actions they should perform on themselves.

Only Smalltalk and Neon provide a true object oriented environment. Ada and Modula-2 only provide you with some level of information hiding; algorithms are still written in the classical style.

Neon

This is an attempt at putting a powerful Smalltalk-like language into the Macintosh. Kriya has taken a potent 1000 word FORTH nucleus and added everything necessary for true object oriented programming, i.e. objects (classes, methods, subclasses) and messaging. They have also enhanced the basic FORTH language with all sorts of nice features for programmers, such as local variables and named parameters. Much of the bite of having to deal with FORTH's simple minded stack is gone, so those of us that dislike FORTH intensely, can enjoy NEON immensely.

NEON does everything one needs to make a standalone (i.e. double-click to start) Macintosh application. Access to the full Macintosh toolbox is there, plus object classes that provide higher level access to most Macintosh objects, e.g. windows.

The documentation for NEON is outstanding. From the begining they acknowledge that object oriented programming is a new concept to most NEON purchasers. Danny Goodman, author of a number of Apple related books and articles, has written a 19 chapter NEON tutorial, which takes you throught NEON's object oriented nature, and the FORTH concepts necessary to write NEON prgorams, step by step.

Also in the Tutorial binder, is a section that describes the NEON system in detail, from the menu bar to putting together a finished NEON application.

A second binder, the reference manual, details every class, and its methods, included with the NEON system. A glossary of all the FORTH and NEON words rounds out the NEON documentation.

In the event that you want even more documentation for NEON, Kriya has provided the source for most the the NEON system above the basic FORTH kernel, as well as an additional complete application.

FORTH compatibility

According to Kriya, NEON will run most FORTH-83 programs with little or no changes. The FORTH heritage of NEON is apparent in its speed, also. Since my Lisa runs at 5 mhz, Kriya provided the Macintosh sieve benchmark of 3 seconds.

Future NEON features

Kriya has several enhancements that they intend to provide over the next 6 months or so. In no particular order, they are:

1. An integrated assembler. (June-ish; right now one could write CODE words by hand assembly. Header and Footer words are provided.)

2. SANE class - objects that implement Apple's SANE floating point standard.

3. Multi-tasking. They already provide two methods for achieving this, which we'll explore in future columns.

4. Memory manager - Kriya says that the Macintosh memory manager is not ideally suited to object oriented programming. A more suitable memory management scheme may be forthcoming if there is user interest.

5. Additional machines - Kriya intends to port NEON to other machines, such as the Amiga. This would give Macintosh/NEON programmers a very fast route into that market.

Kriya plans to provide quarterly updates. For this service they will be charging a $50/year service and update charge. Comparing this to the per/update charge of other firms, this is a reasonable method. They are also extremely interested in user feedback on what enhancements are desired. A library of user developed object classes is also being actively pursued. Users who take the time to add or enhance object classes for more Macintosh objects, or general purpose objects, are encouraged to submit them to Kriya for inclusion in the library.

NEON Pricing

Right now, NEON is $155 direct from Kriya (they will NOT sell through dealers). After June 30th, the price will go up, although final price has not been established, regardless of what the ads currently say. If a computer club registers itself with Kriya, then the club will receive a $15 rebate for every copy of NEON purchased by one of its members.

Blemishes

NEON is a fine, solid product. However, there are a few blemishes on a otherwise highly polished package. Most of these are minor, such as forgetting to turn on the cursor when the system starts (the word +curs will fix that), forgetting to disable the ineffective EDIT menu items, the fact that the rather nice editor is sometimes slow since it wordwraps, and a few other minor things.

However, despite the fact that I was able to compile a full page of such minor details, I only found a single major defect. Even when I deliberately created a system error, the bomb box provided a resume button; more importantly the resume button actually worked!

The one defect is that shows up in several areas. You must close the NEON editor desk accessory before you quit NEON, otherwise NEON will crash the next time you run it. Likewise, if you try to run NEON under the Switcher 2.0, or after using the MDS editor (EDIT), it will crash. The solution is to reset the Macintosh if you have been using EDIT.

Interestingly, the NEON kernel will run; it is the programmer's interface to the kernel, NEON.COM, that seems to cause the problem. Kriya is aware of, and is fixing the problem.

Other Object Oriented Development Environments

NEON is here, today, and works wonderfully. This diehard Pascal, and anti-FORTH, programmer is currently designing some sizeable NEON applications. However, for those of you who don't want to use NEON, there will be alternative object oriented systems available before 1986.

Apple will release new object oriented programming environments this year, which are designed to help produce productive Macintosh programmers.

MacAPP

This Macintosh version of the Lisa Toolkit is due out sometime during the summer. It is a generic Macintosh application written in Object Pascal, an extention of Pascal to support object oriented programming. Apple worked closely with Prof. Wirth to design the new language extentions. Other versions of MacAPP might be available in Smalltalk, Objective C, or maybe NEON.

Smalltalk

The grandfather of the object oriented languages is available from Apple for $45. The catch is that this version is probably a year away from the general public, and requires a megabyte of RAM and a harddisk to run. It is also completely unsupported, and just about undocumented.

Sieve vs Sieve (MacFORTH vs NEON)

There has been some confusion regarding sieve times in NEON. Evidently, the original sieve figure of 3 seconds for NEON was based upon a single iteration of the sieve algorithm. As most people know, the times should be reported for 10 interations of the algorithm. While preparing a true sieve benchmark for NEON, I came across a number of interesting items.

MacFORTH, as reviewed in The Club Mac News (July 1984), comes with a sieve program. There are two things wrong with this program as distributed. First, the implementation of the sieve algorithm is different from that in the Jan '83 issue of BYTE; in fact the MacFORTH program runs almost twice as fast as the BYTE program, in both MacFORTH and NEON.

Converting the MacFORTH program to NEON brought home another problem; NEON is based upon the FORTH-83 standard, whereas MacFORTH is based on the FORTH-79 standard. For example, the CREATE FLAGS statement has different meanings. In FORTH-79, the CREATE statement is roughly equivalent to the VARIABLE statement (with subtle differences for ROM environments), whereas in FORTH-83 it is used to prepare code word definitions.

Second, the sieve program caught the first documented bug in the NEON kernel. The ic! word is "dead meat"; use i c! instead.

( SIEVE #1 - BYTE MAGAZINE JAN '83) 
(MacFORTH 41 seconds, NEON 42 seconds )

8190 constant size
0 variable flags size allot

: do-prime
    flags size 1 fill
    0 size 0
    do flags i + c@
        if i dup + 3 + dup i +
            begin dup size <
            while 0 over flags + c! over + repeat
            drop drop 1+
        then
    loop
    . ." primes" cr
;

: sieve 10 0 do do-prime loop ." Done." cr ;


( SIEVE #2 - MacFORTH distribution)
(MacFORTH 26 seconds, NEON 25 seconds )

8190 constant size
0 variable flags size allot

: primes flags size 1 fill
    0
    size 0 do
        flags i+ c@ if
        3 i+ i+ dup i+
        size < if
        size flags + over i+ flags + do
            0 i c! dup
            +loop
            then drop 1+
        then
    loop
    . ." primes "
;

: sieve 10 0 do primes loop ." Done." cr ;

SCREENBITS: a difference in philosophies

The Mac XL was not designed to be turned on and off continually. In fact, the owner's manuals suggests that it be left on continually, unless it will be unattended for a few days. That is one of the reasons behind the automatic screen dimming; to ensure the long life of the screen. Unfortunately, under MacWORKS, the screen doesn't dim as completely as I would like it to dim.

The first program that I had written on the old Pascal Workshop 2.0 was a program to turn the display completely off. I was in the process of dedicating the internal hard disk to the MacWORKS environment when I got NEON, and decided to use NEON to produce a similar program for MacWORKS. Since I didn't have access to the video level from MacWORKS, I decided just to paint the screen black.

The program, BLACKOUT, illustrates a number of useful concepts. Kriya never assumed that people would use QuickDraw Grafports other than in windows, and didn't provide for their separate initialization. Since windows are behind the menu bar, the menu bar would be visible; thus raw access to a grafport was needed. A new subclass of grafport, VIEWPORT, was created to add the additional messages required.

Also, like all good Macintosh programs, the program is independent of screen size and memory locations.. Lisa Pascal provides a pre-declared Quickdraw rectangle constant, SCREENBITS, whose bounds can be checked for the screen size. In other languages, we must get this information from the quickdraw globals area of memory. The SCREENBITS word , illustrates how one would gain access to a great many global variables, in the properly generic Macintosh way. We find this area of memory by tracing through a series of pointers headed by the current value of the A5 register. This value of this register is kept in a system global in low memory (hex address 904).

All addresses in NEON are relative to a base value. This value is in register A3. Thus, 904 @ would fetch the value at 904 + the contents of A3. The -base word is used to convert from NEON relative addresses to absolute addresses. 904 -base @ fetches the value at absolute address 904.

SCREENBITS was written on the first day I received NEON, and reflects some initial stylistic residue from my limited FORTH background. Reese Warner of Kriya provided an alternative, albiet uncommented, definition that is more representative of proper NEON style. Note the use of local variables. As stated in the NEON manual, the format is

{ [any named parameters] \ [any local vars] -- stack comment }

The BLACKOUT program also shows how easily one can use the toolbox from NEON. Stack based toolbox routines are simply accessed by setting the stack (NEON supplies pack and unpack words for converting from NEON's 32 bit wide integers to the toolbox's 16 bit wide integers). Register based toolbox routines are only slightly more complicated, and will be fully covered next month, when we start to work with the Mac's modem port.

( Blackout - Paints the entire Macintosh)
(screen black and waits for <cr> )

( ViewPort is a subclass of GrafPort)
(that can initialize and paint )

:CLASS  ViewPort  <Super GrafPort

  ( -- ) ( Initialize the grafport structure )
  :M  NEW:     (abs) call OpenPort ;M

  ( -- ) ( Paint the whole grafport rectangle )
  :M  Paint:   paint: PortRect ;M

;CLASS 

ViewPort Port

( Two definitions of SCREENBITS) 
(are provided; edit one of them out for use )

: ScreenBits
    $ 904 -base @ ( currentA5 -- )
    -base @       ( <address of quickdraw globals> --)
    $ FFFFFF86 +  ( <address of screenbits> -- )
    $ 6 +         ( <address of bounds rect> -- )
    dup           ( adr adr -- )
    -base @       ( adr <first point>  -- )
    unpack        ( adr l t  -- )
    rot           ( l t adr -- )
    $ 4 +         ( l t <adr of second point> -- )
    -base @       ( l t point -- )
    unpack        ( l t r b )
;

( Alternative method - uses local variables )
: ScreenBits { \ QDGlobals RectAddr 
top left bot right -- l t r b }
    $ 904 -base @ -base @ -> QDGlobals
    QDGlobals 116 - -base -> RectAddr
    RectAddr @ unpack -> top -> left
    RectAddr 4+ @ unpack -> bot -> right
    left top right bot
;


( WaitCR - waits for a <cr> )
: WaitCR BEGIN $ 0D key = UNTIL ;

( hidemouse - hides the cursor )
: HideMouse call HideCursor ;

( showmouse - shows the cursor )
: ShowMouse call ShowCursor ;

( BlackOut - the word that starts it all )
: BlackOut
    HideMouse           
( hide the mouse so its outline is gone )
    SavePort            
( Save the old grafport - standard Mac behavior )
    New: Port           
( initialize our grafport )
    ScreenBits PutRect: Port  
( and make it the FULL screen size )
    Paint: Port         
( paint the screen black )
    WaitCR              
( wait until the user types a <cr> )
    ShowMouse           
( restore the mouse )
    RestPort            
( restore the old grafport when done - again, SOP )
    Bye                 
( exit back to the finder )
;

Technical Tidbits

The first NEON update disk is almost ready. It should contain classes for SANE variables, sorting, linked lists, 2-d arrays, symbol tables, and other goodies. The Macintosh Developer's SIG of the Philadelphia Area Computer Society is also starting to get into NEON in a big way, and a number of members have mentioned some of the more interesting classes that they are developing for the public domain.

Also from a recent PACS meeting, came a fascinating idea. A member wanted to know how to link in separately compiled object code with NEON programs. My solution: write a NEON definition to load the code resource from disk, branch subroutine to it, and then properly return to NEON with a next,. This could be done under the current system, or with the NEON assembler being developed. If there is some additional interest in this technique, I could demonstrate it in a later article.

From the Mountain

I have a tentative arrangement with Kriya to provided me with a list of the most frequent questions and answers from NEON technical support. These questions and answers will be published in MacTutor as a form of published technical support. Here are some of this month's solutions to problems:

1. Quickdraw pictures are easy to use from NEON, as the following code illustrates:

 " Scrapbook File" openResFile   ( open resource)
 picture myPic                  ( declare a pic object )
 res# init: mypic                ( resource number )
 getnew: mypic                 ( read it in )
 100 100 goto: mypic       ( position it )
 draw: mypic                    ( exercise for the reader )

2. NEON works with standard text files. None of this FORTH screen nonsense.

3. The Clipboard. NEON has a serious problem with the clipboard. For some reason, whenever you use it, the next time you run NEON, it crashes. This problem prevents NEON from running under Switcher, and from running after Edit has been used. Kriya is aware of this problem, and should fix it soon. Interestingly, the problem does not show up in the kernel, only in the user frontend.

Next Month

Starting in the next issue of MacTutor, we will develop a graphics oriented modem program. This month's column is intentionally short so that we could include the description of Scott Watson's protocol, which is built into Red Ryder with this article. We'll define the problem, the necessary classes, and start to develop them next month.