Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Brendan Younger <email@hidden>
- Date: Fri, 11 Feb 2005 11:05:50 -0600
On Feb 11, 2005, at 10:48 AM, Jim Hagen wrote:
At 16:41 Uhr +0200 10.02.2005, Ruslan Zasukhin wrote:
1) It looks very weird that I cannot create Fsref for non-existing
object,
Like we was able do this with FSSpec. What a great idea is behind of
this?
Clearly this entire line of questioning is one for the Carbon list,
but it would seem from a quick glance at the functions and
documentation it looks like you're expected to use FSSpec until you
_need_ to drop down to the FSRef level. This makes sense when you look
at the FSRef structure and realize that it doesn't store the full file
path name.
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.
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