Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: "M. Uli Kusterer" <email@hidden>
- Date: Sat, 12 Feb 2005 00:10:22 +0100
At 8:48 Uhr -0800 11.02.2005, 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.
No, that's definitely wrong. FSSpec is a holdover from the System 7
days and was replaced with FSRefs when HFS+ came around. Use of
FSSpecs is discouraged, because when you create a file using an
FSSpec, the file name's length is limited to 31 characters (the
original HFS limit) and you can only choose one of the traditional
Mac text encodings (or "script codes", as they were called back
then). These *don't* include Unicode.
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,
Yes, those are older apps that still use FSSpecs internally.
and I can imagine using FSRef directly too much can lead to similar problems.
Actually, it can't. If you request the name of a file by FSRef, you
get an HFSUniStr255, which is Unicode and long enough to hold any
file name. Of course, for a print job you should be using the file's
display name anyway, which you can get from Cocoa (NSWorkspace or
NSFileManager, not sure right now), or from Launch Services.
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.
Yes. In most cases you won't need to go outside Cocoa to work with
files. And there's nothing wrong in using Cocoa's POSIX paths for
quick file access, like it's typically done in NSDocument. Just
holding on to a file for a little longer requires you to use other
means. If you intend to keep a reference to a file across restarts of
your app, you need to drop down to AliasHandles, but other than that,
it's really not needed.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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