Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Jim Hagen <email@hidden>
- Date: Fri, 11 Feb 2005 08:48:51 -0800
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.
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 ?
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.
_______________________________________________
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