Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: OOP--What do you think?
Message-ID: <17229@hoptoad.uucp>
Date: 21 Apr 91 23:51:48 GMT
References: <1991Apr10.210516.25812@rice.edu> <51593@apple.Apple.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 96

In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu
(Ryan Richard Koopmans) writes:
>>What I want to know is, is OOP the wave of the future in
>>programming or just a passing fad?  Is it worth learning
>>a new way of programming just to use the TCL?

In article <51593@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>If you already have programmed the Macintosh, then using TCL/MacApp might
>seem like a waste of time, since you do have to fit your code into someone
>else's application framework.  On the other hand, you do get the benefit of
>features that you might not have tackled yet.  (I haven't looked at TCL, but
>I know that MacApp handles a lot of nitty-gritty details that I don't think
>many casual programmers take the time to worry about.)

On the other hand, it's awfully slow to keep up with both Apple's Human
Interface Guidelines (see pop-up menus, for instance) and the features
that people have been using in real commercial applications for years:
features like floating windows, document-window menu bars,
keyboard-walked menus, and so forth.  It doesn't even support a basic
feature like enabling and disabling of dialog buttons depending on
whether there a selection in a list or text in an editable box, which
is Mac 101 stuff.  (The team seemed quite surprised when I mentioned
this as a use for the TDialogView class in Phoenix!)

It can also serve as a straightjacket if your application doesn't fit
MacApp's assumptions.  I had to change TApplication.SetupTheMenus the
other day to make Undo enable at the appropriate times in Cachet,
because we have a single working document and an arbitrary number of
read-only reference documents, and it's necessary to allow changes on a
non-frontmost document under that model.

Then there are maintenance issues.  When you wind up straightjacketed,
there are two things you can do to escape.  One is to change the source.
This presents major problems when there's a new release.  The other is to
copy and edit large methods and make the edited versions your overrides.
This presents exactly the same problem with new releases -- the edited
copy has to be brought into line with the new version.  This is what
we had to do to handle the basic problem of dialog button enabling and
disabling -- we made a new class of dialogs with an overridden PoseModally
method, consisting of the default method plus one line of code.  We've
had to do this a number of places, and I am not looking forward to the
upgrade to 3.0.

MacApp is barely flexible enough for any sort of real commercial
programming, and almost surely too inflexible for anything really
innovative like HyperCard.  A while ago, Keith said that no one who had
used MacApp would ever go back to another way of programming.  After a
year of using MacApp, I would certainly consider starting my next
application from scratch instead.

>I also think OOP is the wave of the future.  As one example, look at the new
>IAC facilities in System 7.  First, implementing IAC in an application will
>be much easier using MacApp 3.0 than if you were trying to do it yourself.
>You will find that there are a lot of little details about when to call
>various routines that could/should be handled for you by an appropriate
>framework.

Which simply says that the low-level interface wasn't designed very well,
and the MacApp team has managed to do better (they think).  This doesn't
say anything at all about object-oriented programming's benefits.

>Second, you should notice that the interfaces to these features (esp,
>AppleEvents) are strongly object-oriented even though they were done in a
>procedural manner.  For example, an AppleEvent is much like an object (there
>are event classes of AppleEvents).

Well then, given the virtues of OOP, you shouldn't need MacApp to make
the system easy to use, should you?

I'm sold on object-oriented programming, but the above are frivolous
arguments.

>You can implement abstractions with a set of utility procedures, but the
>problem is that simple procedures can't be easily customized.  You can vary
>parameters to a call, but you can't modify what goes on inside a procedure.
>With OOP, you can override one method in a class an change a small aspect of
>its behavior.

That is, provided that there is some small method which is perfectly
placed to let you make just the change that you want.  This is rarely
the case.  Far more often, you're faced with the change-source/copy-and-edit
choice described above, which is no better than any other kind of
source code library.

Furthermore, it's almost always necessary to familiarize yourself with
the internal details of the class you are modifying and most of its
superclasses in order to make any nontrivial change.  Just figuring
out where to place an override can be quite demanding.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Do what you wanna, do what you will;
 Just don't mess up your neighbor's thrill.
 And when you pay the bill, kindly leave a little tip
 To help the next poor sucker on his one-way trip."
    - Frank Zappa, "You Are What You Is"