Re: [boost] Mac OS deprecating paths

From: Jesse Jones (jesjones_at_[hidden])
Date: 2002-01-28 19:44:43

At 3:48 PM -0800 1/28/02, Darin Adler wrote:
>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.

Yeah, you'd have to use an alias for that. But the point still 
stands: paths are fragile and Mac users expect to be able to move 
files around.

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

Yeah, I wouldn't be terribly surprised if more and more Carbon apps 
started using paths. After all Cocoa, for the most part, uses paths 
and Apple's attention to HI issues has really slipped in the last few 
years.

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

I was referring to the alias support that was added to Cocoa.

   -- Jesse

--