Now that I’m newly thinking about helping out with another project in Cocoa, it’s getting me thinking about some issues I’ve had with Cocoa.
Let’s start with files.
Here’s a demonstration for you. Open TextEdit and save a file to the desktop. Go to the desktop and move the file somewhere else. Then go back to TextEdit, modify the file, and save it again.
Presto! New file on the desktop.
Do the same thing in BBEdit. No new file appears on the desktop. Instead, the changes are made to the moved file.
Now, some of you are saying, “Ah ha, bug in TextEdit!” Others of you are saying, “Ah, ha, weird behavior in BBEdit!”
This schism is described in detail in the macosx-dev mailing list thread “Paths, FSRef, Alias, Resource Fork, and the Big Schism”.
As an old Mac user, I think the BBEdit behavior is correct – just because you’ve moved a file doesn’t mean it’s in any way different. The most effective argument to the contrary is that many computer users aren’t used to this behavior, because of experience with Windows and Unix-like OSes.
Another argument in the thread is that, in certain circumstances, this isn’t the behavior you want. For developer projects, for instance, you often want the IDE to refer to projects by paths relative to the project or a particular location. Moving a file doesn’t mean changing the path, it means removing that file from consideration in the project.
I had already gone down this route with my now-abandoned Toolbox-based MacTADS. Writing your own framework does give you the freedom to, say, come up with your own, appropriate file classes.
But I do think that, apart from those special cases, I as a user would rather have the BBEdit behavior. So it distresses me (a) that Cocoa does not have a real file class, and (b) that I so often see NSString substituting for a file reference.