Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Ed Baskerville <email@hidden>
- Date: Fri, 11 Feb 2005 12:55:12 -0500
On Feb 11, 2005, at 12:05 PM, Brendan Younger wrote:
That's backwards. Don't think of FSSpec's as being "higher level";
they aren't. FSRef's are *always* the way to go if the file already
exists. If the file doesn't exist, then you can take your pick from
paths, FSSpec's, Aliases, etc. to refer to it.
In the traditional Mac OS world, this was the accepted convention. I'm
not sure what the accepted convention is now, nor have I come to a firm
conclusion myself, but I've heard the opposite case made fairly
convincingly along these lines:
Say you're using an app that has the notion of a "project" that
contains references to other files. It stores both pathnames and FSRefs
to these files. The user has previously made a backup of one of these
files in a different location, and, after making some changes to the
file, decides to revert to the backup. They* move the file out of its
current location, and move the backup to where it just was, so that the
project begins using the backup rather than the file with the unwanted
modifications.
If you lean on FSRefs as your primary method of referring to files, the
app will do exactly the opposite of what the user wanted: it will
continue to use the file that was just moved, rather than the backup
that was put in its place. If the user understands FSRefs, they won't
be surprised by this--but can we expect users to understand FSRefs?
Note that Xcode, certainly, uses POSIX paths as its only way of
referring to files. (And Xcode users are far more likely to understand
FSRefs than, say, Flash users--but, as discussion on this list makes
evident, it can't be assumed even there.) It would perhaps be nice if
it could lean on FSRefs as a backup, but if you move a file and replace
it with another file of the same name in the same location, chances are
you want it to use the *new* file, not the old one.
But I may yet be convinced of the superiority of the FSRef-first
approach. :)
--Ed
* fast becoming an accepted gender-nonspecific singular pronoun
Ruslan, if you're interested in the equivalent Cocoa functionality,
it's easy to find :
file:///Developer/ADC Reference Library/documentation/Cocoa/
FileManagement-date.html#//apple_ref/doc/uid/TP30000416-TP30000448
and the relevant Carbon docs, which I didn't see anyone point you to :
file:///Developer/ADC Reference Library/documentation/Carbon/
FileManagement-date.html#//apple_ref/doc/uid/TP30000420-TP30000448
The "File Manager Reference" contains many important bits of info,
like "You should not access File Manager structures directly if
accessor functions for the structure exist."
On Feb 10, 2005, at 12:11 PM, M. Uli Kusterer wrote:
Well, I don't have to worry about FSRefs. NSDocument uses them
internally anyway.
--
Wouldn't NSDocument use NSFileHandle ?
No, because NSFileHandle requires the file to be open for either
reading or writing. There's no particular reason for NSDocument to
keep the file open all the time. FSRef's provide a way to track the
file even when not open.
Of course, I suppose NSFileHandle could lean on FSRef and FSSpec,
though I don't know it should need to. I've seen Carbon apps pass the
mangled name[31] to other parts of the system, like for printing, and
I can imagine using FSRef directly too much can lead to similar
problems. Programming in Cocoa, we're pretty insulated from this kind
of stuff. NSData and NSDocument do the heavy lifting for us,
generally. I likewise can't think of the last time I used even
NSFileHandle directly.
Just to clarify: you can *never* go wrong with an FSRef. The name
mangling that FSSpec's are prone to doesn't exist with FSRef's.
Please don't think for a moment that paths or URLs (i.e. the Cocoa
way) is to be preferred for any reason other than convenience.
Brendan Younger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden