From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: NeXT vs. Mac programming
Followup-To: comp.sys.mac.advocacy
Organization: Taligent, Inc.
Date: Thu, 12 Nov 1992 02:01:12 GMT

In article <1992Nov9.203132.9310@cubetech.com>, you wrote:
> 
> Otherwise you stille have to translate all your QDGX code to PS to
> print (if possible).  Additionally, if it's not written by Adobe, then
> there is no guarantee that you will get the same thing on the printer

Yes you have to do a translation, which is what happens today with regular
QuickDraw.  My impression of QDGX (I don't know much about the details) is
that it more closely matches Postscript so the translation would be easier.
 

As far as not being from Adobe, Adobe doesn't change Postscript all that
often and the behavior of Postscript is pretty well defined.  The process
would be analogous to writing a compiler for a certain CPU.  If the
instruction set of a CPU is well defined there's no problem writing a
compiler for it.

> Well, since the printer can't understand QD, you have to generate the
> PS code somewhere.  It depends on what you are doing.

The Postscript printer driver generates the PS code in most cases.  The
places where it doesn't are because QD doesn't have the required
capability.  (That is, there is no way in QD to describe the desired
output.)  Presumably the number of these cases will decrease with QDGX.

> You are also not limited to views with IB.  You can do things with any
> object (and define your awn objects within IB as well).

IB is definitely better than anything on the Mac, but the Mac tools are not
as primitive as you made them out to be.

> Yes, but how easy/difficult is it to use AppleEvents.  With DO's I

In this kind of discussion, it's important to distinguish the regular Mac
programming interface from something like MacApp.  The procedural interface
to Apple events is hard to use.  The support that MacApp provides for Apple
events makes them much easier to use.  MacApp doesn't have anything like
DO, but it could (except for the 32K Apple event limitation).

> You've sent me mail before about this and you've always used the same
> example - "undo and documents."  An Undo object is provided in 3.0 and

I did a quick look though the 3.0 documentation and didn't see one.  Then
someone else pointed out that one of the sample apps comes with a Changes
object.  That didn't seem to be part of the AppKit itself.  Is this not
correct?

> really I can't see the point of a document object besides the Object
> superclass.

The document object in MacApp handles the details of creating and
manipulating the disk files for saving the document data.  It keeps track
of whether the document needs saving, puts up the standard alerts, checks
for free disk space, etc.

> If having MacApp and all these other tools was as good as having and
> object-orient operating system like NeXTSTEP, Apple wouln't be
> spending all this money on Pink/Taligent.

MacApp is not the be-all of application frameworks.  And it's not better
than what NeXT has in all areas.  MacApp suffers from the problem of being
layered on top of the procedural Mac interface, which means that (as on the
NeXT) programmers have to deal with both programming paradigms.  It's also
held back by the limitations of the underlying Mac system.

Pink goes way beyond what MacApp provides.  I don't have an in-depth
knowledge of NeXTSTEP, but I belive Pink goes way beyond what NeXT provides
as well.  (But of course I won't be able to convince anyone of that right
now.)

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com