Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!eagle!bparsia
From: bparsia@eagle.wesleyan.edu
Newsgroups: comp.sys.mac.programmer
Subject: Reforming Mac Programming (longish, ~60 lines)
Message-ID: <13828@eagle.wesleyan.edu>
Date: 25 Mar 90 21:07:19 GMT
Lines: 60

Perhaps some of you with more experience with object-oriented programming (OOP)
will comment.

Someone mentioned in another post in another group (the post part of the "why
can't Apple ][ users accept the mac" thread) that the bewildering variety of
Macintoshs has lead to an unacceptable set of conditions one must check and
take into account when programming. Color QuickDraw is one example of such a
condition. I was wondering what could be done to simplfy programming on the Mac
for everyone except the ROM and system programmers (sorry, someone has to
suffer). Some things (like CQD) have to be taken care of by the appl.
programmer (if you are writing a color paint package, you'd better make the
color calls), but other conditions should be transparant, as far as possible,
to the "end" programmer.

For example, numeric coprocessors. THINK Pascal (along with most other packages
I hope) has a 68881 compile option which generates optimized code for the
coprocessor if you check it off. Now, why doesn't Apple just set up a standard
numeric enviroment (i.e. SANE), included in the system or the ROM, written in
blazingly fast and clever assembly language, and tailored to each machine. Thus
the SANE in the SE ROM would just use the 68K to do the work, while the SANE in
the II series would be optimized for the coprocessor. The upshot is: both have
the same interface, allowing one to do the coding once, and each implementation
in the ROM (or the system, whatever) would take care of making the call in the
best possible way for that system. No mess, no fuss, on compile and the program
is oblivious to the differences (the user isn't, there is just one version of
the program and it runs great).

Now, take the idea a step further. What if Apple implemented a MacApp type
class library and stuck *it* in the ROMS, optimized (of course) for the
particular machine. Thus the MacApp II in the II ROMs could take advantage of
the nifty '020 features, the MacApp IIci in the IIci ROMs could take advantage
of *its* nifty features (burst mode something or other, etc.), the the MacApp
IIfx in the IIfx ROMs could take advantage of its nifty features--features which
now (I believe) are up to the individual programmers to figure out and use.

The advantage: Consistently high quality code, tailored to the special features
of each machine. Guarranteed optimal performance. 

More pros: If you put it on fast ROMs, the processor wouldn't need as large a
cache or as clever progamming to reach zero wait states.
The end programmer binaries would be quite small in many cases (except
where the programmer did extensive alteration of the classes, but even then,
programs would mainly be a series of calls to the ROM). Better code
compatibility--as long as you keep the interface basically the same, the
progams will run). Along with that, a greater degree of hardware independance.
More application consisitency--if the human interface is in the ROMs, and will
both lower one's application size and improve (in most cases) performance *and*
insure (almost) complete compatibility with now and future machines, people
will use it.

Cons: A hell of a lot of work for apple, but it would generate good software
and sell machines.


I think there are more advantages, but this post is long enough.

I invite comments. Is this scheme possible, practical, silly? Other cons, other
advantages, dissenting views; all are desired.

Bijan J. Parsia