lippin@brahms.berkeley.edu (The Apathist) (06/29/90)
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.
tim@efi.com (Tim Maroney) (06/30/90)
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 modifying 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. In article <1990Jun28.173027.18044@agate.berkeley.edu> lippin@math.berkeley.edu writes: >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. You are incorrect. There is no need to "Remove Objects". I have just checked this (as you could have done rather than making false assumptions). The THINK Pascal application is intelligent enough to figure out that the file it compiled before is not the same as the file that now has that name, using the date on the file. And yes, I do consider it an obvious technique to switch objects by switching their names. I've observed people doing this for years. Switching folders is one way; and even more common way is, as I said, renaming a file to "Old <file name>" and then copying over a new version from another volume (floppy disk or network volume, usually) and calling it "<file name>". I think it strains credibility to say that this is not an obvious technique -- do you ever watch users?; it is an obvious technique that will not work if file ids are used. >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. I don't see what relevance this personal attack has, since I'm not a techno-geek. I'm a transplanted humanities type. However, if the personal attack is removed, the paragraph seems to be left with very little meaning. I think that most people are quite aware that if the school keeps records on their children, and the names of the children are switched, then one will wind up with the others' grades.