Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacApp examples Was: Local/AppleTalk Connectivity in MacApp
Message-ID: <14582@hoptoad.uucp>
Date: 5 Jan 91 21:15:41 GMT
References: <1991Jan3.221839.21979@athena.cs.uga.edu> <14545@hoptoad.uucp> <47760@apple.Apple.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 48

In article <14545@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>Incidentally, MacAppers -- please ignore the example programs shipped
>>by Apple.  They are very small and do not scale well.  If you adopt the
>>unit strategy of the example programs, in which everything knows about
>>the applications and document subclasses and those subclasses know
>>about everything else, you will not be able to expand beyond a few
>>source files or do much information hiding or code reusability.

In article <47760@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes:
>I don't think that the intention with the MacApp samples was to
>create huge scalable applications. Instead they try to show how to
>extend the *MacApp* framework. It is up to the developer to create
>own object hierarchies and attach these to the MacApp framework in
>strategic suitable places.

I would think that an example program for a class library ought to show
a good style of use for the class library, not just to show that, hey,
it actually does compile and run....  Examples are to emulate.

>>Instead, the strategy to use is:  Your application and document
>>subclasses do know about everything, but hardly anything knows about
>>them.  They are "master controllers" which are unknown to most of the
>>things they control.  This will lead to a lot of USES in the units
>>dealing with document and application subclasses, but a manageable
>>number elsewhere.

>That's exactly the current trend with application frameworks. Isolate
>and connect at few places - sort of data abstraction in the class
>level.

I'm glad to know that I'm in tune with the latest thinking.  I do wish,
however, that some attempt had been made to communicate this thinking
together with the class library, instead of forcing me to discover it
myself.

Not only did I have to figure it out rather painfully over a period of
months, I had to contest with a fellow programmer who learned MacApp
from Apple's course and the example programs, who would always say,
"But look, in the example programs this is how the units are connected;
that's how Apple wants you to do it."

Please, let's get some examples that reflect a good class style.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"It is better to be a human being dissatisfied than a pig satisfied;
 better to be Socrates dissatisfied than a fool satisfied."
	-- John Stuart Mill, UTILITARIANISM (1863)