From: Darin Adler (darin_at_[hidden])
Date: 2002-01-28 18:48:25
On 1/28/02 3:32 PM, "Jesse Jones" <jesjones_at_[hidden]> wrote:
> That's one reason. The other reason is that paths are fragile. If the
> user moves a file while the program is running bad things will
> happen. If the app saves a path in a pref or something and the user
> later moves it bad things will happen. This is *bad*: Mac users don't
> know about paths or file systems. All they see are icons in the
> Finder and they expect to move almost everything wherever they want.
But FSRefs are fragile too. If an application tries to save an FSRef in a
preference it won't work. I agree that Macintosh provides some nice ways to
store file locations that are better.
[I do understand this issue. I was the engineer who designed the first cut
at the Alias Manager to deal with this in the late 80s when I worked in
Apple System Software (although Prashant Patel did most of the coding and
changed the programming interface considerably). ]
> OS X complicates things. It's essentially three platforms in one: BSD
> Unix, Cocoa (the NeXT Objective-C app framework), and Carbon (an
> updated version of the Mac OS 9 APIs). These are all native
> applications, but only BSD Unix and Cocoa use paths (and Cocoa's
> dependencies upon paths are being reduced). I strongly doubt that
> many Carbon apps are using paths (and the majority of OS X apps are
I'm not going to debate this one with you. Suffice it to say that Carbon has
a nice set of calls that convert POSIX paths to and from FSRefs, and that I
have used them in my Carbon programs.
You talk about "dependencies on paths", I agree that those should be kept to
a minimum. It's very inflexible to rely on certain files being at hard-wired
locations. But this has little to do with the question of whether programs
should use paths internally to represent file system locations.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk