Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Local/AppleTalk Connectivity in MacApp
Message-ID: <14545@hoptoad.uucp>
Date: 4 Jan 91 20:47:39 GMT
References: <1991Jan3.221839.21979@athena.cs.uga.edu>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 54

In article <1991Jan3.221839.21979@athena.cs.uga.edu> fore@athena.cs.uga.edu
(Howard Fore) writes:
>Ok, you MacAppies:                     
>
>1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there
>   prewritten methods and classes to deal with this? I need to write a program
>   that will communicate across a LocalTalk LAN to retrieve a text file from
>   a hard drive. Will I have to write the routines myself for going across  
>   LocalTalk? Any advice?

There are no built-in methods.  It doesn't seem (and I'm familiar with
both domains) that it would be hard to create object wrappers for the
Appletalk driver calls.  And it does seem that they would be useful in
program beautification.

Higher-level objects could then be built to do what you want in terms
of file transfer and so forth.  They wouldn't be very useful for
implementing other people's protocols, which would require going down
to the lower-level object wrappers.  But they would be very useful for
making up your own applications which could rely on these higher-level
services.

>2. The APDAlog lists MacApp 2.0 as being available on a CD as well as 10 disks.
>   It also mentions various "goodies" that are on the said CD with MacApp. What
>   are these "goodies"?

Nothing extraordinary.  Some MPW scripts that are somewhat useful for
MPW developers, that's all I remember.  Maybe they're also including
ViewEdit, example programs, and unsupported modifications under
"goodies".

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.

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.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"In science it often happens that scientists say, 'You know that's a
 really good argument; my position is mistaken,' and then they actually
 change their minds and you never hear that old view from them again.
 They really do it.  It doesn't happen as often as it should, because
 scientists are human and change is sometimes painful.  But it happens
 every day.  I cannot recall the last time something like that happened
 in politics or religion." -- Carl Sagan, 1987 CSICOP keynote address