Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!brahms.berkeley.edu!lippin
From: lippin@brahms.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to Openresfile -- Actually on IDs (file and directory)
Message-ID: <1990Jun28.173027.18044@agate.berkeley.edu>
Date: 28 Jun 90 17:30:27 GMT
References: <13401@unix.SRI.COM> <1990Jun25.180531.532@efi.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: lippin@math.berkeley.edu
Organization: University of California, Berkeley
Lines: 47

Recently tim@efi.com (Tim Maroney) said:
>With System 7.0 on the way, I think it's time to re-open this question
>of the usefulness of file IDs.  I have recently discovered a case which
>shows that even the use of directory ids to store paths is a bad idea.
[...]
>Since I'm modfifying MacApp, when I have problems, it makes sense to
>see if the problem also happens on an unmodified MacApp.  So I keep a
>folder of virgin sources with my folder of modified sources.  Sometimes
>I switch the two, by using the Finder's folder renaming feature, to
>test under virgin conditions.

And then you use the "Make" command to rebuild?  No, the make command
would see that the already compiled code is newer than the sources you
slipped in, and do nothing.  Instead, you used your knowledge of the
internals of the application to force it to forget everything it knew
about the contents of the files.  (I imagine you used "Remove
Objects.")  Yes, I do the same thing.  But I wouldn't count on it
working in any application, and I wouldn't consider it an obvious
technique.

To me, using tricks like this depends on a misstep common among
programmers: "the name is the object."  This appears to be less
common, although not entirely absent, among non-techno-geeks.*  Few
think that by naming their kid George Bush, they can make him
president.

[...]
>The problem
>will only get worse when file ids rear their ugly head, and as Matt has
>pointed out, even the preliminary support for this feature leads to
>hard-to-find bugs.

Matt's hard-to-find bug wasn't a problem with file ID's; it was a
problem with documentation.  He overlooked the double-headed arrow in
the description of PBGetCatInfo, and missed entirely the description
of what was passed back over the arrow -- probably because that's
thirty pages earlier.  More of an argument for rewriting Inside
Macintosh than for getting rid of file ids.

* "Techno-geek" is an unregistered trademark of Brita Meng.

					--Tom Lippincott
					  lippin@math.berkeley.edu

	If you call a tail a leg, how many legs does a dog have?

	    Four.  Calling a tail a leg doesn't make it one.