Re: [boost] Mac OS deprecating paths

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
> Carbon).

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.

    -- Darin