Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.sys.mac
Subject: Re: HyperCard stack multi-access
Message-ID: <2046@sputnik.COM>
Date: Mon, 19-Oct-87 19:39:25 EDT
Article-I.D.: sputnik.2046
Posted: Mon Oct 19 19:39:25 1987
Date-Received: Tue, 20-Oct-87 22:47:30 EDT
References: <1051@cive.ri.cmu.edu> <1335@elrond.CalComp.COM> <1990@sputnik.COM> <30928@sun.uucp>
Sender: news@tc.fluke.COM
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 29

>o Technical: Trying to save and batch changes would take an amazing amount
>	of memory and the overhead woul slow things down significantly.
>	To do what Hypercard does at the speed it does, they had to do it
>	this way.

How about making a copy of the file you are opening?  Hardly a
revolutionary idea: replace the old file with the new one when doing a
save; if there isn't enough disk space throw up a dialog saying that
changes will be permanent.  Sure that hurts perfomance, but only when
opening and closing files.

>o Design: A good claim can be made that every time you push a button (or
>	type in a field, etc...) that you've made an impllicit agreement to
>	save with the application, so an explicit save isn't necessary. Many
>	applications work this way on the mac (one example: filemaker plus).

Perhaps this is a "religious" matter, but this is the only defense I
have heard of Hypercards auto save (even the Apple reps I have talked
to agreed it is a Bad Thing).  It gives people a warm fuzzy feeling to
know they can screw up and easily recover by simply not saving
changes.

Hypercard is an amazing piece of software, but what ever happened to
the wonders of a standard user interface?  No, it should not grow
cobwebs, but change for the sake of change is to be avoided.


Brian McElhinney
mce@tc.fluke.com