Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Jason Jobe <email@hidden>
- Date: Fri, 11 Feb 2005 19:46:44 -0500
You might be interested in Nathan Day's NDAlias
http://homepage.mac.com/nathan_day/pages/source.html
On Feb 11, 2005, at 6:23 PM, M. Uli Kusterer wrote:
At 12:55 Uhr -0500 11.02.2005, Ed Baskerville wrote:
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.
If it stores FSRefs, it's screwed. Neither FSRefs nor FSSpecs are
guaranteed to be valid across launches of your app. With FSSpecs you
could sometimes get away with it, but only as long as the order of
drives on your computer didn't change (then the volume refNum would
change, and your references would be useless).
And your expectation of how project files would work comes from the
fact that you're used to paths, and you expect C to use paths for
locating headers. That's how GCC expects it, too, and since Apple
didn't want to completely rewrite GCC, they didn't change that.
Usually, when actual end-users move a file to another folder, they
don't expect it to lose its connection. It's still the same file.
I guess when you use an xCode project, you expect the folder
containing the project to be special. In that case, xCode should work
by scanning the current folder, and, like iTunes with its library, it
should reorganize the directory as is suitable. It's just a case of
metaphor and, at least in my opinion, xCode doesn't really have a
clean metaphor. But that's okay, because programmers expect it to work
that way since they're used to it.
But as I said in my previous message, Cocoa does most of this right
already (I think the "recent files" list still occasionally lost track
of moved or renamed files, but that's it) if you're using NSDocument,
so no need to mess with this unless you plan to go low level.
And I think that's it from me on this topic. This is really getting
farther and farther away from being Cocoa-related.
--
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:
email@hidden
This email sent to email@hidden
- jason
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